I don't wish to belabor, but you completely ignored all of my (and
Monty's) arguments.  Yes, there *is* a sort-of "contract" that
#isEmpty should be implemented in terms of #size, and not #do:, that
is now being violated.  I explained why earlier and you even said it
was a point worth discussing, but never did.  The comment that was
added to Collection>>#isEmpty advertises the flawed thinking.

The flaws with all of your other statements were addressed in prior
posts, too.  I don't know why any of the advocates for this change
couldn't address or even acknowledge those arguments.  Even the
comment that was added to Collection>>#isEmpty advertises the flawed
thinking.  I hope someone will go back and really _read_ the arguments
being made in this thread.

Just saw Franks note.  Same thing..    :(



On Wed, Oct 26, 2016 at 11:35 AM, 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.
>
> - Bert -
>
>
>
>