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

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?

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

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


On Sat, Mar 13, 2010 at 12:30 AM, Andreas Raab <andreas.raab at gmx.de> wrote:
> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>