On Wed, Oct 26, 2016 at 11:41 AM, Chris Muller <asqueaker@gmail.com> wrote:

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.

I don't see any such contract. Collection has a contract; to be fully functional as a collection class the subclass must implement #do:. This is stated; #do: is a subclass responsibility of Collection. I see no stated contract that #isEmpty is implemented in terms of #size. Given that in Collection #size is implemented in terms of #do:, we are free to implement #isEmpty et al in terms either of #do: or of #size. The new implementation is better for large collections, works for infinite collections, and is hence to be preferred.

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.

I don't see what's special here. We've given arguments for the change; both Bert and Frank (effectively, in my view) refuted your arguments against the change. This is no different than other performance-related changes that have been made in the past. You have yet to present an example of code that is broken ny this change.

Just saw Franks note. Same thing.. :(

Looked pretty cogent and on point to me.

On Wed, Oct 26, 2016 at 11:35 AM, Bert Freudenberg <bert@freudenbergs.de> wrote:
> On Wed, Oct 26, 2016 at 6:42 AM, Chris Muller <asqueaker@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 -
>
>
>
>

_,,,^..^,,,_

best, Eliot