[squeak-dev] Fixing support for selectors with underscores

Tobias Pape Das.Linux at gmx.de
Tue May 3 10:57:50 UTC 2011


Am 2011-05-02 um 20:28 schrieb Levente Uzonyi:

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

yes, why not?

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

oO I thought #allowUnderscoreSelectors was Class-side, too…, however,
how to specify to use underscores on the class side?

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

Concerning what?
I'm using per-class scoping for some projects.
(that is, for parser, compiler and shout-parser)
Ometa also does.

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

Hmm, a loadable superclass that does this kind of "configuration" ?
> 
> 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.

depends.
If you think about backwards-compatibility, this is no issue, the
existing code should not interfere with the new, underscory one.
If you have newer code that wants to use the underscory code,
well, then you probably have to enable underscores for that particular case, but
I don't think that this is especially an issue.

So Long,
	-Tobias


More information about the Squeak-dev mailing list