On 26 October 2016 at 09:35, 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.

+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 -