On Tue, 3 May 2011, Tobias Pape wrote:

>
> Am 2011-05-02 um 20:28 schrieb Levente Uzonyi:
>>
>> What would it mean that e.g. a SmallInteger returns true to #allowUnderscoreSelectors?
>>
>
> yes, why not?

I guess you misread my question.

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

Currently there's no way to specify that. The difference between 
#allowUnderscoreSelectors and #parserClass is that you don't want to 
change the parser of the class side, but you may want to use underscores 
in class side methods (or even class names).

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

See above why this problem is different.

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

How does that solve the issue with class names and class side methods?

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

Did you try to use a package that has underscores in selectors or class 
names?


Levente

>
> So Long,
> 	-Tobias
>