[squeak-dev] Files-ul.154 seems dangerous, is it needed?

Levente Uzonyi leves at caesar.elte.hu
Wed Jun 1 08:40:09 UTC 2016

Hi Dave

On Tue, 31 May 2016, David T. Lewis wrote:

> That said, in the case of setting a stream to #binary or #ascii, the
> #adoptInstance: approach does seem fragile compared to #asByteArray.
> If Behavior>>adoptInstance: fails, the fallback code attempts to use
> Object>>primitiveChangeClassTo: which also fails, this time with no fallback
> path. Thus if the primitives for changing the class of an object fail,
> there is no fallback and it may no longer be possible to write a new binary
> file (such as new image and changes files).

You would still get a debugger in such case where you would have a chance 
to fix/work around the problem, wouldn't you?

> Another way to look at it - if the optimization is worthwhile, maybe it
> belongs in the Collections package, which already needs to be different
> for Spur versus V3.
> For Spur, shouldn't it just be this:
> ByteString>>asByteArray
>     ByteArray adoptInstance: self
> I did not really test this, but it should give us the same performance
> optimization in a more general way.

This would significantly change the behavior, because currently you know 
that a copy will be returned.
We might as well use a different selector (#toByteArray or #beByteArray), 
but I don't know if that would help V3 images.


> Dave

More information about the Squeak-dev mailing list