[FWIW, I'm not taking any sides here, just explaining some intentions]

On 5/2/2011 20:28, Levente Uzonyi wrote:
>> 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.

You'd use a different superclass (possibly in a separate package). I've 
done similar things quite effectively before. It's a bit icky and 
nothing you'd do casually, but if you're porting a larger subsystem it 
can be done with reasonable effort. Here's an example of how I'd do it:

Object subclass: #FooObjectStub

FooObjectStub class>>allowUnderscoreSelectors
	^self ~~ FooObjectStub

etc. This allows one to use the system defaults in FooObjectStub while 
providing the proper settings for the subclass tree.

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

Yes. But then again, this was intended to allow porting sizable chunks 
of code where one can then deal with the remaining problems as well.

Though, given how little use it has had, I wouldn't claim that it's been 
particularly effective :-)

Cheers,
   - Andreas