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 -