[squeak-dev] Fixing support for selectors with underscores

Igor Stasenko siguctua at gmail.com
Mon May 2 23:18:38 UTC 2011


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.  ;)

>>
>> 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 .

>
> Levente
>



-- 
Best regards,
Igor Stasenko AKA sig.



More information about the Squeak-dev mailing list