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 at 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&spellToler=standard&sectHdr=off&tableBorder=1&cmpType=relaxed&lang=en
	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.