On Wed, Oct 26, 2016 at 11:41 AM, Chris Muller <asqueaker at 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 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 -
> >
> >
> >
> >
>
>


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20161026/08c58101/attachment-0001.htm