[squeak-dev] Re: Selectors with underscores: Have your cake and eat it, too...

Bert Freudenberg bert at freudenbergs.de
Tue Mar 16 11:20:19 UTC 2010

On 16.03.2010, at 05:13, Andreas Raab wrote:
> 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

Sounds good to me.

And I'm pretty sure we'll get rid of underscore assignments in Etoys too. Since we don't use the bitmap fonts anymore it just looks plain ugly anyway. So newer code tends to use := already. It just has not been a priority so far to convert old code.

- Bert -

More information about the Squeak-dev mailing list