I wrote: > To expand on this a little: why not give programmers a way to build > a sorted collection in linear time when they are able to provide data > in the right order?
Stephan Rudlof sr@evolgo.de wrote: I'm not against this. But please don't use addLast: for this.
I don't see any reason why not. It perfectly expresses the intent. It's an existing method. The last thing we need is lots of twisty little methods all slightly different.
However, the _best_ approach is to have _no_ such methods but simply to make #add: work efficiently. (This illustrates why jumping into the first patch one thinks of is not such a good idea.) > - we should avoid introducing operations that often don't work Agreed: this is my point regarding >>addLast: introduced for SortedCollections: it always works for OrderedCollections, but only in very special cases, if applied to SortedCollections. I am opposed to *introducing* such operations.
> - but when we are stuck with an operation that CAN be allowed to > proceed some of the time we should not be strict bondage and > discipline nannies and stop sensible programmers doing sensible > things. This is a contradiction to the previous point: 'proceed *some* of the time' ('*' by me) violates the goal to 'avoid introducing operations that often don't work'. Not a contradiction at all. I wasn't suggesting *introducing* such an operation, but fixing an operation that *already exists*.
> The attitude here is > - I am like God; I know exactly how programmers think and they mustn't. I know what I expect from calling >>addLast:. And I know what I expect. However, I don't know what you expect; you don't know what I expect, and neither of us knows what Jill Neighbour expects. What matters is what's *documented*, not what we think she expects.
> Using >>addLast: for a SortedCollection means to try to give an > explicit order to something, which has an automatically 'built > in' one. This mostly is a programmer error. > > I am not sure how to interpret "mostly" here. > If it is an empirical statement about how often it does happen, > then I would be intrigued to know where the evidence came from. It's not an empirical statement. For me it is a convention to expect an OrderedCollection if using >>addLast: (also see below). If it's not an empirical statement, we don't have any grounds for a 'mostly' here. As for "if method is #addLast: then receiver is OrderedCollection", so much the worse for B3DFillList LinkedList POSimplePolygon and RunArray, eh? (I'd agree with you that LinkedList is unlikely, but can we really afford to forget about RunArray?) My point is: if I'd use >>addLast: I'd expect an OrderedCollection, *not* a SortedCollection.
Again, RunArray>>addLast:.
If I understand you, you are basically saying that whatever Smalltalk thinks to the contrary, SortedCollection isn't _semantically_ a subclass of OrderedCollection.
And ANSI supports this kind of view. I am very keen on arguments from the ANSI standard. But I'd really like to see chapter and verse on this one.
I still don't have a copy of the final standard, but the 1.9 draft says some funny things about SortedCollection.
For example, it says of "x, y" when x is a SortedCollection "Answer a new collection containing all of the receiver's elements in their original order followed by all of the elements of operand, in their original order." but also says "Since the receiver sorts its elements, the result will also be sorted as defined by the receiver's sort block." (Yes, I've read the other bits here.)
Now it seems to _me_ that redefining concatenation to be merging is bad practice; an intention revealing name should be used. Note that it isn't a simple matter of concatenating or even of merging two sequences; if the operand is not itself sorted it must be sorted.
The ANSI specification of #copyReplaceAll:with: is rather puzzling. Basically, aSortedCollection copyReplaceAll: aSortedSubsequence with: elements does this: if aSortedSubsequence occurs as a subsequence of aSortedCollection, remove those elements, then send addAll: elements to aSortedCollection otherwise make no change.
Now this example is very much apropos. It takes a method which is normally thought of as strongly positional, 'abcd' copyReplaceAll: 'bc' with 'xyz' ==> 'abxyzcd' NOT 'abcdxyz' keeps the positional search part, and turns the normally positional replacement part by a sort/merge part.
In the same way, aSortedCollection copyReplaceFrom: start to: stop with: elements chops out a positionally determined subset, then does a non-positional add.
If we took this as our model, then #addLast: would be allowed and would be identical to #add:. (NOT a change I favour.)
What we _do_ want for sorted collections, and are not given by ANSI, is methods that copy or remove a slice based on element contents rather than element positions: aSortedCollection copyAbove: minval below: maxval aSortedCollection removeAbove: minval below: maxval or something like that.
> "performant" is, to the best of my knowledge, not an English word. > I certainly haven't been able to find it in any of the paper or > electronic dictionaries I've just checked. Try "faster". I'm wondering, because Leo knows it: http://dict.leo.org/?search=performant&searchLoc=0&relink=on&spe... But it may be wrong: you are the native speaker! I note that LEO is provided by a German university. The page I get there when I search for 'performant' does not give any citations or definition. The little 'm' points to the Merriam-Webster dictionary, which is one I checked, and it says quite plainly "The word you've entered isn't in the dictionary."
It appears that "Performant" is a German word masquerading as English. I have no idea what it means in German. Perhaps it is a word English needs.
But I stay at my assumption to expect an OrderedCollection if using >>addLast:. And if you introduce methods *** with the same name *** in other protocols you break conventions (and ANSI is also a convention). You only break conventions if you do not follow the conventional rules about refinement. The way ANSI refines methods for SortedCollection provides ample precedent for refining the *inherited* (NOT "introduced") method #addLast:. As noted above, some of the ANSI refinements for SortedCollection strike me as bizarre. Order-respecting #addLast: is almost unbelievably tame by comparison.