On Tue, 3 May 2011, Igor Stasenko wrote:

> On 2 May 2011 20:28, Levente Uzonyi <leves at elte.hu> wrote:
>> On Mon, 2 May 2011, Tobias Pape wrote:
>>
>>>
>>> Am 2011-05-02 um 05:49 schrieb Levente Uzonyi:
>>>
>>>> Hi,
>>>>
>>>> since Squeak 4.1 it's possible [1] to use underscores in class, method
>>>> and variable names. System wide support for them is still incomplete though.
>>>> There are two reasons for this:
>>>> - our developement process doesn't need this feature
>>>> - noone wanted to fix it
>>>>
>>>> The per-class scoping causes so much trouble, that I'd like to remove it
>>>> completely, leaving only global preferences. Why?
>>>> - It doesn't work for
>>>>  - class names,
>>>>  - class variable names,
>>>>  - class side methods.
>>>> - It doesn't work with code loading tools (e.g. Monticello), because
>>>> there's no guarantee, that #allowUnderscoreSelectors will be loaded before
>>>> the methods using underscores that way.
>>>> - It doesn't work for tools viewing external code.
>>>>
>>>> Any objections?
>>>
>>> Yes, I think per-class scoping is important.
>>> I think it is valuable to be able to ?tune?
>>> your sub-tree of the inheritance tree without interference
>>> with the system. I don't think it is wise to force
>>> the whole system to be underscore-selector compatible
>>> because three or so classes (just an example) need them.
>>> Especially, these three classes never know what setting
>>> they are loaded into. Perhaps there is some very old code
>>> that chokes on underscores, so why enable them globally when
>>> it is not needed globally. I'd even opt for the preference
>>> #allowUnderscore* to be implemented on Object, so this is only
>>> virtually global.
>>
>> What would it mean that e.g. a SmallInteger returns true to
>> #allowUnderscoreSelectors?
>>
>>>  Make as least things global as possible.
>>
>> Pharo took the easier way: no underscore assignments. So underscores are
>> allowed everywhere else. AFAIK they didn't face any problem with this
>> approach. We have much better backwards compatibility even with the system
>> wide preferences.
>>
>
> But unable to recompile all classes in system without chances to get a
> syntax error,
> because some code are imported using one preference and another using
> different one.  ;)

It's the user's responsibility, as usual. Trunk code doesn't use 
underscores at all, so recompilation is not an issue IMHO.

>
>>>
>>> You said:
>>>>
>>>> - It doesn't work with code loading tools (e.g. Monticello), because
>>>> there's no guarantee, that #allowUnderscoreSelectors will be loaded before
>>>> the methods using underscores that way.
>>>
>>> I would take that as a reason to fix monticello.
>>> It is the same problem for #parserClass #compilerClass
>>
>> Similar case, but IIRC class side methods are loaded before instance side
>> ones, so these don't cause any trouble.
>>
>>> etc.pp. You don't want to remove that support, too, do you?
>>
>> AFAIK noone proved that per-class scoping is possible to do at all.
>> How would you fix the case, when a class has underscores in it's name? You
>> can't load the class side selector, before loading the class itself, can
>> you?
>> How would you fix class side methods? You can't add methods to the
>> metaclass.
>>
>> Another flaw with the per-class scoping is that not only the implementors,
>> but the senders/users of such methods/variables/classes has to enable
>> underscores in selectors.
>>
>
> Indeed. A per-class scoping is just an attempt to play nicely, but it
> not covers all possible cases of course.
>
> That's why i was always for:
> - uniformly change all sources to use := for assignment, and allow to
> use underscore in identifiers/selectors.
>
> - for legacy code add a code importer tool, which could while
> loading, replace relevant _
> with := and then proceed as normal.
>
>
> AFAIK Pharo had little problems with not supporting old underscores at all.
> Fixing the source code takes minutes: just fileout .st files (or
> whatever), then open your preferable
> text editor and replace all '_' occurences with ':=' , except from
> rare cases where underscore are
> used in comments/string literals .

You can't be serious about the text editor and find & replace. 
FixUnderscores was a crap that did exactly this. No wonder why noone liked 
it. We (or at least I) have a proper tool for changing underscore 
assignments to ansi ones which is based on Scanner. It's a lot easier to 
do the change in in the image IMHO: change the preference, load the code, 
replace the assignments, restore the preference.


Levente

>
>>
>> Levente
>>
>
>
>
> -- 
> Best regards,
> Igor Stasenko AKA sig.
>
>