You're right the inconsistency isn't nice, but performance shouldn't be
affected, so that is strange...

About the inconsistency, I don't really see that ByteString>>byteAt:put:
should do coercion. If the caller already knows they're putting a byte, than
make sure that you're doing that. On the other hand, at:put: is the generic
interface and for objects that can only accept bytes here, they should a)
fail when it's not a byte or b) be nice and try to coerce it.

My goal was to make the primitive truly optional again. That's what the test
case is designed to check (although that also is also a bit brittle). I
tried to find a small change that doesn't duplicate code and that passes the
tests. Changing the fallback code in SequenceableCollection may also be
possible, but I didn't want to add handling of byte subclasses there.

That being said, the fact that the primitive allows me to at:put: a
Character into a ByteArray seems inconsistent in any case (an artifact of
the underlying representation in the C?). If those characters are implicitly
converted into SmallIntegers in the byte range, why then can't we also put
Characters into WordArrays, for example?




--
View this message in context: http://forum.world.st/The-Trunk-Collections-tfel-613-mcz-tp4818483p4818782.html
Sent from the Squeak - Dev mailing list archive at Nabble.com.