Richard A. O'Keefe
ok at cs.otago.ac.nz
Wed Jun 23 05:37:30 UTC 2004
> copied: nTimes
> ^self species streamContents: [:s |
> nTimes timesRepeat: [s nextPutAll: self]]
Fine, that's a more general idiom. I presume you mean copy/copied: in
analogy to new/new: in which case I would transform it to
copy/copySize: since Slate dropped new: very early on for newSize:
(yes, I know it's a capacity in general). I can do this because I
control Slate. I don't want to hear about Squeak or Smalltalk-80.
If you don't want to hear about Squeak or Smalltalk-80, why post in
a Squeak mailing list? I think Slate is interesting, the PMD stuff
looks exciting, and I have absolutely *no* suggestions to make about
what Slate should or should not do.
You don't specify the behavior of copySize: for non-unity-sized
But yes, I *did* specify it. I gave the *full* code.
^self species streamContents: [:s |
ntimes timesRepeat: [s nextPutAll: self]
And that's precisely why the name #copySize: would be very VERY badly
chosen; the argument is NOT (in general) the size of the result, it is
the NUMBER OF COPIES of the receiver which are concatenated. The fact
that the receiver is not restricted to being (or having) a single element
is what #copied: is all about.
and it's ill-definable for non-Sequences,
And I don't *want* it defined on anything that concatenation isn't
defined on. Like the code says, it's defined for SequenceableCollection.
It's even possible that there is an inconsistency in making a
copy protocol that feeds values where they weren't before
(Sequences being Mappings when you have Traits).
I have no idea what you are talking about. The operation I propose
takes a sequence and returns the result of concatenating it n times.
There is no inconsistency in this that there isn't already in
concatenation; there are no values where they weren't before.
(1) Treating arrays of codes as Characters is not attractive.
I am not sure what you mean. The point of mentioning Unicode was that
the "n copies" operation should NOT be defined on Characters because
there are things that look like single "characters" which CAN'T be
represented as Characters but CAN be represented as Strings. Treating
arrays of codes as characters is the very opposite of my intent;
#<xxx xxx xxx> is NOT a Character, it is a String.
Unicode is a real pain in many ways. For example, in ASCII and MacRoman,
aString asLowercase size = asString asUppercase size
but in Unicode this is not in general true. In particular, there are
quite a few Unicode characters where case-shifting must deliver a String,
not a Character. Dealing with Unicode is so much simpler if you don't
even try to deal with Characters, only with Strings. (And yes, I have
tried to design Unicode character and string classes for Smalltalk. Ouch.)
By the way, as a person who records and aggregates your each and every
word on this mailing list about library and language design and the
specifications and so forth, I very much appreciate your opinion, and
do not mind so much the abrasive tone and the haranguing, but I do not
think that this tolerance is shared by others, probably for the reason
that they have no motivation to aggregate the information.
You may be *hearing* an abrasive tone, but I am not *writing* in an
Single-sentence suggestions do not need (even after two stages) 10
pages of rhetoric to make the counter-point.
Since you do not seem to have understood what my Smalltalk implementation
of #copied: was meant to do, perhaps more pages were needed.
We've probably shouted
down any possibility of code being written; I hope not.
On the contrary, I *have* written (and quoted again at the top) suitable
Whoever wants this, write the darned thing and it'll get approved!
In the form of an operation that applies to an *element* and constructs
a result of a fixed class, it should not be. Or do we need more pages to
make that point?
More information about the Squeak-dev