[squeak-dev] Re: The defaullt implementation of isEmpty might do too much work

Frank Shearar frank.shearar at gmail.com
Wed Oct 26 17:42:19 UTC 2016


On 26 October 2016 at 09:35, Bert Freudenberg <bert at freudenbergs.de> wrote:

> On Wed, Oct 26, 2016 at 6:42 AM, Chris Muller <asqueaker at gmail.com> wrote:
>
>> I agreed that it looked good in the ivory tower.  The thing is, there
>> are these real-world detractors which we should not igore.  To save my
>> old fingers, let me just summarize them from the earlier posts.  In
>> summary:
>>
>>   - it provides no known material benefit
>>
>
> Having an O(1) runtime vs O(n) is a very large material benefit.
> Collection>>size is O(n) so it's not a good base for #isEmpty.
>
>
>>   - it could affect unsuspecting legacy application performance
>> materially, and in an insidious way
>>
>
> If you have performance problems, profile.
>
>
>>   - it's an anomalous usage of the API which works against performance
>> expectations about #size and #do:.
>>
>
> The performance expectation of both #size and #do: in Collection is O(n).
> And there is nothing "anomalous" in using #do:, quite to the contrary, #do:
> is the *essence* of a collection of objects.
>
>
>>   - the justification for this change (performance optimization) in
>> Collection is not valid in the first place.
>>
>
> It is very valid optimization given the implementation of Collection>>size.
>
>
>> No real-world positives, just negatives or zeros.  Please revert.
>>
>
> Quite the opposite. It's a major improvement in basic API.
>
> Yes, you will have to provide an optimized #isEmpty now, because you
> relied on an implementation detail of a superclass.  But there never was a
> contract that #isEmpty needs to be implemented in terms of #size. The new
> implementation makes much more sense for an arbitrary abstract Collection,
> so I'd like to see it stay.
>

+1. Especially since we've seen examples of Collections where #size just
doesn't make sense: generators, Actor-style mailboxes, Xtreams (and, by
extension, all reactive APIs).

Which is exactly why in C# an IEnumerable (a Collection) doesn't even have
a Count method. (It's added as an extension, and People Know(tm) to be
careful using it on an abstract collection.)

Really, to be properly Ivory Tower, and Elegant, Collection's #size should
be removed. And as Eliot correctly points out, the only elegant way to ask
a Collection about which you know nothing, whether it has any elements, is
to _evaluate its first value_.

I can't give real world Smalltalk experience reports, but I can say, with
many burn marks to prove it, that asking an abstract collection of things
for its size, is a terrible idea.

frank


> - Bert -
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161026/62d2eb78/attachment.htm


More information about the Squeak-dev mailing list