[squeak-dev] Selectors with underscores
Ken G. Brown
kbrown at mac.com
Thu Mar 11 22:30:34 UTC 2010
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:
>>- Ian Trudel
>>- Andreas (but vote PRO depend on backwards compatibility aspect)
>>- Stéphane (votes for scoping)
>>NOT CLEARLY STATED
>>- 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
>>>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  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?
>>GMX DSL: Internet, Telefon und Entertainment für nur 19,99 EUR/mtl.!
More information about the Squeak-dev