Am 2011-05-03 um 15:09 schrieb Levente Uzonyi:

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

Oh, sure.
It would mean that every class that descends from SmallInteger
can use underscore selectors.

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

Yes.

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

Well if this class is loaded first, we can ask it for the config
and apply it to the subclasses.
> 
>>> 
>>> 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?

I have to admit, no, not yet.
But I want to do some gemstone-things, where underscore selectors
are more common, so I will hit these issues :)


So Long,
	-Tobias