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

Bert Freudenberg bert at freudenbergs.de
Wed Oct 26 16:35:42 UTC 2016


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.

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


More information about the Squeak-dev mailing list