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.
Hi
I'm searching for a way to fill a Morph with more than one Color. I hope 'fading Color' describes it well. The best example is the MoviePlayer from the Widgetsflap but I didn't find how to get this working. Can you help me ?
Regards Chris Burkert
Chris Burkert christian.burkert@s2000.tu-chemnitz.de wrote:
Hi
I'm searching for a way to fill a Morph with more than one Color. I hope 'fading Color' describes it well. The best example is the MoviePlayer from the Widgetsflap but I didn't find how to get this working. Can you help me ?
Regards Chris Burkert --
Chris,
have a look at MPEGMoviePlayerMorph>>moviePlayerFillStyle. and search the senders of this method.
The point is that you have to define a GradientFillStyle. Such a thing has an array of colors. Try this for different values of direction (100 @ 0, 100@50, 100 @ 100) to get a feeling for fading coloring:
| fill bc |
fill _ GradientFillStyle ramp: { 0.0 -> (Color r: 0.05 g: 0.5 b: 1.0). "blue" 0.5 -> (Color r: 0.70 g: 0.85 b: 1.0). "almost white" 1.0 -> (Color r: 0.05 g: 0.5 b: 1.0)}. "blue again" fill origin: (50@0); direction: 100@0; radial: false. bc := BalloonCanvas extent: (200 @ 100) depth: 32. bc fillRectangle: (0@0 extent: 200 @ 100) fillStyle: fill.
bc form displayAt: 10@ 10
Hope this helps
Boris Gaertner wrote:
Chris Burkert christian.burkert@s2000.tu-chemnitz.de wrote:
I'm searching for a way to fill a Morph with more than one Color. I hope 'fading Color' describes it well. The best example is the MoviePlayer from the Widgetsflap but I didn't find how to get this working. Can you help me ?
Chris,
have a look at MPEGMoviePlayerMorph>>moviePlayerFillStyle. and search the senders of this method.
The point is that you have to define a GradientFillStyle. Such a thing has an array of colors. Try this for different values of direction (100 @ 0, 100@50, 100 @ 100) to get a feeling for fading coloring:
| fill bc |
fill _ GradientFillStyle ramp: { 0.0 -> (Color r: 0.05 g: 0.5 b: 1.0). "blue" 0.5 -> (Color r: 0.70 g: 0.85 b: 1.0). "almost white" 1.0 -> (Color r: 0.05 g: 0.5 b: 1.0)}. "blue again" fill origin: (50@0); direction: 100@0; radial: false. bc := BalloonCanvas extent: (200 @ 100) depth: 32. bc fillRectangle: (0@0 extent: 200 @ 100) fillStyle: fill.
bc form displayAt: 10@ 10
Hope this helps
Thanks a lot. That's exactly I was searching for.
Regards Chris Burkert
You can make gradients by hand. Make sure the "property sheet" preference is on in "Preferences". Then click on the property sheet halo handle (near lower right corner). The sheet allows you to set colors, transparencies, gradients, drop shadows, etc.
I made the MoviePlayer look in just a few seconds. Note that the gradient tool allows both directions and origin to be changed ...
Cheers,
Alan
-----
At 5:14 PM +0200 9/30/02, Boris Gaertner wrote:
Chris Burkert christian.burkert@s2000.tu-chemnitz.de wrote:
Hi
I'm searching for a way to fill a Morph with more than one Color. I hope 'fading Color' describes it well. The best example is the MoviePlayer from the Widgetsflap but I didn't find how to get this working. Can you help me ?
Regards Chris Burkert --
Chris,
have a look at MPEGMoviePlayerMorph>>moviePlayerFillStyle. and search the senders of this method.
The point is that you have to define a GradientFillStyle. Such a thing has an array of colors. Try this for different values of direction (100 @ 0, 100@50, 100 @ 100) to get a feeling for fading coloring:
| fill bc |
fill _ GradientFillStyle ramp: { 0.0 -> (Color r: 0.05 g: 0.5 b: 1.0). "blue" 0.5 -> (Color r: 0.70 g: 0.85 b: 1.0). "almost white" 1.0 -> (Color r: 0.05 g: 0.5 b: 1.0)}. "blue again" fill origin: (50@0); direction: 100@0; radial: false. bc := BalloonCanvas extent: (200 @ 100) depth: 32. bc fillRectangle: (0@0 extent: 200 @ 100) fillStyle: fill.
bc form displayAt: 10@ 10
Hope this helps
--
Richard,
to ease reading the following, please take a look at the attached screenshot first.
Richard A. O'Keefe wrote: <...>
- 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*.
addLast: doesn't exist for the <SortedCollection> *protocol*, if I've
understood ANSI correctly (see below). And the <SortedCollection> protocol does *not* inherit from <OrderedCollection>! That is, what I've meant with introducing a not existing operation.
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:.
RunArray isn't defined by the standard as I see it.
If I understand you, you are basically saying that whatever Smalltalk thinks to the contrary, SortedCollection isn't _semantically_ a subclass of OrderedCollection.
Exactly (almost)! Smalltalk 'thinks' in class inheritance, the standard in protocol conformance/inheritance.
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.
<...>
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:.
<...>
From ANSI draft v1.9 (if you'd need it e.g. as *indexed* (very practical)
PDF, I could send it to you): ------ 5.7.17 Protocol: <SortedCollection>
Conforms To <extensibleCollection> <sequencedContractibleCollection> <sequencedReadableCollection> Description Represents a variable sized collection of objects whose elements are ordered based on a sort order. The sort order is specified by a <dyadicValuable> called the sort block. Elements may be added, removed or inserted, and can be accessed using external integer keys. Messages , add: asSortedCollection collect: copyReplaceAll:with: copyReplaceFrom:to:with: copyReplaceFrom:to:withObject: copyReplacing:withObject: reverse sortBlock sortBlock: ------
<SortedCollection> does *not* conform to <OrderedCollection> which is the only one defining >>addLast:.
About conformance and refinement: ------- 5.1.3 Conformance and Refinement
Protocols are related to each other through two substitutability relationships, conformance and refinement, which arrange the protocols in a lattice. Conformance models requirements satisfaction, and provides the flexibility to partially constrain the behavior of parameters and return values without necessarily naming specific classes. Refinement allows a protocol to make more precise statements about behavior inherited from another protocol. -------
Note: here the term 'inherited' is applied to protocols, not to class inheritance!
As I've understood 'conformance' describes inheritance from other protocols. As an example the Dictionary protocol hierarchy: ------ 5.7.2 Protocol: <abstractDictionary>
Conforms To <collection> Description Provides protocol for accessing, adding, removing, and iterating over the elements of an unordered collection whose elements are accessed using an explicitly assigned external key. <...> ------ 5.7.3 Protocol: <Dictionary>
Conforms To <abstractDictionary> Description Represents an unordered collection whose elements can be accessed using an explicitly assigned external key. Key equivalence is defined as sending the #= message. Messages none
5.7.4 Protocol: <IdentityDictionary>
Conforms To <abstractDictionary> Description This protocol defines the behavior of unordered collections whose elements can be accessed using an explicitly-assigned, external key. Key equivalence is defined as sending the #== message. Messages none ------
Now I've found something better: in 5.7 there is a nice graphics showing the conformance relationships between protocols. I've attached a screenshot.
There you can see that <SortedCollection> really does *not* inherit the <OrderedCollection> protocol!
And this is also the reason, why >>addLast: is *not* refined by <SortedCollection>: it doesn't need to.
Hopefully I've reduced confusion a little bit.
Greetings,
Stephan
squeak-dev@lists.squeakfoundation.org