<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 26, 2016 at 11:41 AM, Chris Muller <span dir="ltr"><<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't wish to belabor, but you completely ignored all of my (and<br>
Monty's) arguments. Yes, there *is* a sort-of "contract" that<br>
#isEmpty should be implemented in terms of #size, and not #do:, that<br>
is now being violated. I explained why earlier and you even said it<br>
was a point worth discussing, but never did. The comment that was<br>
added to Collection>>#isEmpty advertises the flawed thinking.<br></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The flaws with all of your other statements were addressed in prior<br>
posts, too. I don't know why any of the advocates for this change<br>
couldn't address or even acknowledge those arguments. Even the<br>
comment that was added to Collection>>#isEmpty advertises the flawed<br>
thinking. I hope someone will go back and really _read_ the arguments<br>
being made in this thread.<br></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Just saw Franks note. Same thing.. :(<br></blockquote><div><br></div><div>Looked pretty cogent and on point to me.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Wed, Oct 26, 2016 at 11:35 AM, Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br>
> On Wed, Oct 26, 2016 at 6:42 AM, Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>> wrote:<br>
>><br>
>> I agreed that it looked good in the ivory tower. The thing is, there<br>
>> are these real-world detractors which we should not igore. To save my<br>
>> old fingers, let me just summarize them from the earlier posts. In<br>
>> summary:<br>
>><br>
>> - it provides no known material benefit<br>
><br>
><br>
> Having an O(1) runtime vs O(n) is a very large material benefit.<br>
> Collection>>size is O(n) so it's not a good base for #isEmpty.<br>
><br>
>><br>
>> - it could affect unsuspecting legacy application performance<br>
>> materially, and in an insidious way<br>
><br>
><br>
> If you have performance problems, profile.<br>
><br>
>><br>
>> - it's an anomalous usage of the API which works against performance<br>
>> expectations about #size and #do:.<br>
><br>
><br>
> The performance expectation of both #size and #do: in Collection is O(n).<br>
> And there is nothing "anomalous" in using #do:, quite to the contrary, #do:<br>
> is the *essence* of a collection of objects.<br>
><br>
>><br>
>> - the justification for this change (performance optimization) in<br>
>> Collection is not valid in the first place.<br>
><br>
><br>
> It is very valid optimization given the implementation of Collection>>size.<br>
><br>
>><br>
>> No real-world positives, just negatives or zeros. Please revert.<br>
><br>
><br>
> Quite the opposite. It's a major improvement in basic API.<br>
><br>
> Yes, you will have to provide an optimized #isEmpty now, because you relied<br>
> on an implementation detail of a superclass. But there never was a contract<br>
> that #isEmpty needs to be implemented in terms of #size. The new<br>
> implementation makes much more sense for an arbitrary abstract Collection,<br>
> so I'd like to see it stay.<br>
><br>
> - Bert -<br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>