Selectors with underscores: Have your cake and eat it, too...

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

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

> 2010/3/12 Andreas Raab<[hidden email]>:
>> 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
>>
>>
>>
>>
>
>
>

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

> 2010/3/13 Andreas Raab<[hidden email]>:
>> 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.
>
> All right. I believe it is not as much appealing as it would have been

> 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<[hidden email]>:
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>

>
> On 3/15/2010 10:29 AM, Chris Muller wrote:
>> -1 so far.
>>
>> I may not have thought this completely through, but this potentially
>> opens up another splinter of division; wherein some packages will use
>> underscore selectors, some won't.
>
> In theory, yes. But I don't think this is very likely. First, if we declare usage of underscores illegal in all core images we've already solved most of the problem. If we advocate to avoid underscore usage, most people will follow our lead.
>
>> So I suppose, at some point, those who would otherwise have underscore
>> selectors turned off, must turn them on to load and use such a
>> package?
>
> Unless the package has the proper class annotations, yes. Hopefully this will create pressure on the people who provide these packages to provide proper class annotations and/or avoid using underscores.
>
>> I didn't see a response to the question about loading stuff in; will
>> we now start getting errors during load about my preference
>> incompatible with
>
> Yes. Just as you get errors right now if you're trying to load code with underscore selectors, and just as you're getting errors right now if you try to load code with underscore assignments in Croquet. The situation isn't new; you are getting these errors already under various circumstances. What's new is that you can do something about it.
>
>> Overall, to me it seems like a lot of complexity, not just for the
>> system but for the user to have to think about, all just to accomodate
>> a *naming preference* for RDBMS mapper softwares?  I say preference,
>> because, UNDERSCORE_COLUMN_NAMES can easily be converted to and from
>> smalltalkMethodNames.
>>
>> I think we need to think this through..
>
> That's what we're trying in this discussion. I understand your concern, and largely agree with it. But the situation today isn't better - we're getting errors already without being able to do anything about it. Glorp patches the scanner; how's that for ugly?
>
> My point is that we can lead by being consistent in saying no to underscores altogether in the base system. This allows us to set the release properties to whatever we decide the useful default is, while allowing individual users or entire projects (Etoys for example) to decide how they would like to use it.
>
> Cheers,
>  - Andreas

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