[squeak-dev] Files-ul.154 seems dangerous, is it needed?
leves at caesar.elte.hu
Wed Jun 1 08:40:09 UTC 2016
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:
> 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.
More information about the Squeak-dev