[squeak-dev] Re: Selectors with underscores: Have your cake and eat
andreas.raab at gmx.de
Tue Mar 16 04:13:07 UTC 2010
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
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
> 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.
More information about the Squeak-dev