Fixing support for selectors with underscores

> 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?
>
>
> Cheers,
> Levente
>
> [1]
> http://forum.world.st/Selectors-with-underscores-Have-your-cake-and-eat-it-too-td1591416.html
> [2] http://bugs.squeak.org/view.php?id=7547
>
>

> Well... Glorp and GlorpDBX (squeakDBX's Glorp Port) Package, uses some
> accessor with underscore... to maintain compatibility with VW Version
>
> to fix it we have this script
> http://www.squeakdbx.org/files/01/315sh0cs3b31mska30xb1nnigblvdu/underscore.cs
>
> I 'm not sure, if that break other thing, but Glorp Work well..
>
> Best
>
>
> On Mon, May 2, 2011 at 12:49 AM, Levente Uzonyi <[hidden email]> wrote:
>> 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?
>>
>>
>> Cheers,
>> Levente
>>
>> [1]
>> http://forum.world.st/Selectors-with-underscores-Have-your-cake-and-eat-it-to
>> o-td1591416.html
>> [2] http://bugs.squeak.org/view.php?id=7547
>>
>>

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

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

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

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

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

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

> On Tue, 3 May 2011, Igor Stasenko wrote:
>
>> On 2 May 2011 20:28, Levente Uzonyi <[hidden email]> 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.  ;)
>
> It's the user's responsibility, as usual. Trunk code doesn't use underscores
> at all, so recompilation is not an issue IMHO.
>
>>
>>>>
>>>> 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 .
>
> You can't be serious about the text editor and find & replace.
> FixUnderscores was a crap that did exactly this. No wonder why noone liked
> it. We (or at least I) have a proper tool for changing underscore
> assignments to ansi ones which is based on Scanner. It's a lot easier to do
> the change in in the image IMHO: change the preference, load the code,
> replace the assignments, restore the preference.
>

>
> Levente
>
>>
>>>
>>> Levente
>>>
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>>
>
>
>
>

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

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

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