[squeak-dev] The Trunk: Collections-eem.784.mcz
ma.chris.m at gmail.com
Sun Mar 11 01:23:53 UTC 2018
>> 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
(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...
More information about the Squeak-dev