Richard A. O'Keefe
ok at cs.otago.ac.nz
Fri Feb 14 01:38:12 UTC 2003
"Andreas Raab" <andreas.raab at gmx.de> wrote:
> Anyway, I think I have made my case for #collect:into:
Yes, but where's the code?! Properly prefixed with an [ENH][FIX] the
harvesters may actually have a chance to find it.
(1) The point of my message, as I hoped was clear, was that
Set>>collect: should *NOT* be fixed.
The message was not a [FIX] or an [ENH] but an *anti*[FIX],
a clear statement "Set>>collect: ISN'T BROKEN so DON'T 'fix' it."
If that point is accepted, I will be as happy as Larry,
because that was 95% of the point of the message.
(2) The code for an improved String>>collect: was right there in the
message, but I am firmly opposed to putting such a thing where the
harvesters might see it until there has been some discussion about
whether it's a good idea.
What should String>>collect: do if the block returns a value that
is not a character? Pop up an obscure error message (like now)?
Pop up a helpful error message? Return an Array?
It's not just String. What about ByteArray and other specialised
arrays? Ideally, this thing should really be in Array, and it
should use the 'accepts:' message I posted about a long time ago.
(Is 'accepts:' in yet?) Instead of
(flag or: [item isCharacter])
it should be
(flag or: [result accepts: item])
otherwise a lot of specialised code...
(3) collect:into: was described for Set. It would need to be implemented
for each Collection class that currently defines #collect:.
But what is the point of writing it and posting it when we have been
told (today) that things like that WON'T go into the next release?
And above all, when we've been told that there is a whole new refactored
set of Collections using Traits?
Give me a 90% probability that #collect:into: will be added to 3.4 final
(if available in time) and I'll make the effort.
More information about the Squeak-dev