Seems like underscores in selectors should be allowed. A single underscore as a selector would mean assignment.

I don't personally like underscores as assignment but they could be allowed by preference but only if they had whitespace either side.

x _ z would be ok equivalent to x := z

And disallow underscore as assignment without whitespace either side.

x_ z or x_z not ok for assignment, they would be taken as selectors.

And encouragement should be provided for preferentially using := going forward.
Seems like a simple enough solution, or am I missing something?

Ken G. Brown

At 11:04 PM +0100 3/11/10, radoslav hodnicak apparently wrote:
>I'm for having underscores in selectors, and a preference seems like a simple enough solution
>
>On Thu, 11 Mar 2010, Torsten Bergmann wrote:
>
>>Until now we have:
>>
>>PRO
>>- Torsten
>>- Edgar
>>- Bert
>>- Alexander
>>- Matthew
>>- Keith
>>- Igor
>>
>>CONTRA
>>- Ian Trudel
>>- Sam
>>
>>SCOPING
>>- Andreas (but vote PRO depend on backwards compatibility aspect)
>>- Stéphane (votes for scoping)
>>
>>NOT CLEARLY STATED
>>- Louis
>>- Randal (vote seem to depend on Preference, which we now have)
>>- Radoslav (but would rather ban underscore assignment, than
>>            underscores in method names)
>>- Ralph Boland
>>- Nicolas
>>
>>>There's a lot of code that uses at least x_ foo (i.e., no space between >var name and underscore).
>>
>>With the Preference disabled you have Squeak as it was before and
>>there should be no problem to load this code. At least if you dont
>>have packages with "_" selectors. And if thats not enough a simple
>>lint rule can check that _ selectors are not used in a base/core image.
>>
>>I dont know about the Etoys codebase that much but is it really relying
>>on the missing space here?
>>
>>If not the code can be automatically converted while loading as Matthew
>>suggested in [1] today. An alternative would be to do the homework
>>(as with other stuff like #fixTemps and friends) and update the
>>code when moving to newer Squeak?!
>>
>>The Refactoring browser also has a nice function to convert _ to := assignments (in the lint tool).
>>
>>>I'm wondering: I don't really know how the people who want underscores
>>>plan to use this, but would it make sense to scope this differently,
>>>i.e., either on a per-class or even a per-method basis?
>>
>>Scoping? Why? A preference is
>> a) simple
>> b) settable by the image owner who is able to decide if he
>>    wants to allow it or not (same as with underscores)
>>
>>>Per class would be my favorite because in a system where you'd like to
>>>use underscores globally you'd just have Object
>>>class>>allowUnderscoreSelectors return true.
>>
>>You mean this for real? I thought we would clean up the system
>>instead of putting anything into (already bloated) base classes .... ;)
>>
>>And is it a class who allows underscore selectors or is it the compiler?
>>
>>Bye
>>Torsten
>>
>>[1] http://lists.squeakfoundation.org/pipermail/squeak-dev/2010-March/146419.html
>>--
>>GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
>>http://portal.gmx.net/de/go/dsl02