On 3/12/2010 9:22 PM, Ian Trudel wrote:
> I like the manner you have presented this. Concise information. There
> is a question that seems to be not addressed (or not as clear as I'd
> like) in your email. What happen if one switches from one preference
> to another after having extensively used it? Is there some kind of
> conversion taking place?

No. If you switch the interpretation of underscores mid-way, you deserve 
swift punishment and you shall receive it :-) This is supposed to be a 
pretty static default and like I was saying I'd be in favor of 
disallowing underscores altogether for baseline development. In which 
case you'd turn on one or the other in situations where you may need it, 
for example when porting code using underscore assignment, or when 
loading a library that comes from a system using underscores.

> Say, both are turned on, a programmer write a lot of "d _e =>  (d) _e".
> Then I use the image and set allowUnderscoreAssignments on,
> allowUnderscoreSelectors: off. What happens to the expression? Will it
> become "d _e =>  d := e" ? That sounds nasty.

Existing expressions retain their interpretation unless you recompile.

Cheers,
   - Andreas

> 2010/3/12 Andreas Raab<andreas.raab at gmx.de>:
>> Folks -
>>
>> Attached my take on selectors with underscores. It basically separates the
>> issue of using underscores in assignment from the issue of using underscores
>> in selectors, puts this into two individual preferences, and allows
>> per-class scoping while providing a system-wide default.
>>
>> The possible combinations of preferences are:
>>
>> * allowUnderscoreAssignments off, allowUnderscoreSelectors: off
>> The use of underscores is forbidden, i.e., the Croquet model.
>>
>> * allowUnderscoreAssignments on, allowUnderscoreSelectors: off
>> The classic Squeak usage; all of the following are assignments:
>>
>>         a _ b   =>                a := b
>>         b_ c    =>                b := c
>>         d _e    =>                d := e
>>         f_g     =>                f := g.
>>
>> * allowUnderscoreAssignments off, allowUnderscoreSelectors: on
>> The standard usage in other dialects
>>
>>         a _ b   =>                ((a) _) b
>>         b_ c    =>                (b_) c
>>         d _e    =>                (d) _e
>>         f_g     =>                (f_g)
>>
>> * allowUnderscoreAssignments on, allowUnderscoreSelectors: on
>> The hybrid usage requiring spaces around underscore for assignment:
>>
>>         a _ b   =>                a := b
>>         b_ c    =>                (b_) c
>>         d _e    =>                (d) _e
>>         f_g     =>                (f_g)
>>
>> This gives us a range of options to decide how to deal with it. I would
>> personally say that for the core image we should go with the first option
>> (disable underscores altogether) and only enable whichever option we like
>> for the release.
>>
>> What do people think about this approach? I think it provides the most
>> options and gives us ample flexibility to decide what we'd like to use down
>> the road.
>>
>> If there is no fundamental opposition I'll push it into the trunk in a
>> couple of days.
>>
>> Cheers,
>>   - Andreas
>>
>>
>>
>>
>
>
>