[squeak-dev] Fixing support for selectors with underscores

Igor Stasenko siguctua at gmail.com
Tue May 3 01:30:17 UTC 2011


2011/5/3 Levente Uzonyi <leves at elte.hu>:
> 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.
>
Not a problem. As long as you doing change.
But if you forgetting to do it, then your image contains a mixture of
classes which using different underscore syntax convention
which leads to inability to recompile all classes.

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



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list