Hi Levente,

>> Forgive me, Eliot, but I feel that is a negative change.  An elegant
>> class-library design should use as high-level public methods as it
>> can, and have as _few_ methods as possible that make calls to private,
>> implementation-specific code (e.g. scanFor:).  Especially in abstract
>> classes like Dictionary.  I know its not technically abstract, I'm
>> referring to the fact that it is the superclass for many different
>> subclasses, including ones in other packages which this change did not
>> consider -- I'd bet this will break some of them, and the irony will
>> be that they'll be forced to duplicate the elegance that existed
>> before in multiple subclasses.  :(
>>
>> If you are working from a tight loop, you could consider letting the
>> _style_ of the code advertise its intention to be efficient by calling
>> the lower-level method(s) directly from there.  If anything, calling the
>> higher-level one could actually lose that intent on the reader...
>>
>> It seems this only saves a couple of extra method sends, but for a new
>
> It saves block creation and activation besides sends, and those cost more
> than you might think.

Anyone who cares about block-activations won't use that method in the
first place.  It's optimizing from the wrong place, and desecrating
the class-library to do it.  It's sad, actually, because the
Smalltalk-80 class-library supposedly has a reputation for being
something regular people can read and understand.

The net-effect is Eliot is able to make code that almost no one will
ever read only slightly prettier, but in a self-defeating way, since
the use of the high level message obscures its performance-critical
nature.  All this at the expense of significantly worse readability
and compatibility emanating from the core class-library -- code that
regular people, end-users, WILL read.  In a sense, this change almost
feels selfish.

(from your other post)
> I'm strongly against external packages subclassing collections (exactly for this reason: it limits what core developer can do),...

As I explained, above, the core developer is not constrained in any
way.  I think you stated the real limitation above -- that we can't
safely subclass Collection because of changes like this.

>> person to understand, because they'll more likely know what
>> #at:ifAbsent: does than #scanFor:.  It forces them into the
>> implementation prematurely, even though OO is supposed to let them
>> "not care how it works".
>
> It only forces them if they want to understand the code. And then it's not a
> problem, because that's exactly what they want, isn't it?

I was referring to forcing the users to cross that boundary from
something they care about -- "WHAT it does" to something they don't --
"HOW it works".    By defining high-level implementations "in terms
of" other public methods they already know, they don't even need to
know about #scanFor: at all, much less how it works...

Best,
  Chris