[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] [PATCH] Fix #1136 and a question about type specia
Re: [Chicken-hackers] [PATCH] Fix #1136 and a question about type specialisation
Tue, 15 Jul 2014 09:35:14 +0200 (CEST)
>> I'm unsure how to fix this. Is it fixable at all? Is it worth fixing?
> The only thing I can think of is for the scrutinizer to pre-check for
> a call to object-become! and disable itself. The trouble is that the
> effects may be pervasive to anywhere in the code, given the power of
> call/cc to execute code out of order.
That's correct. As "object-become!" can mutate any value in arbitrary
ways, and thus makes any assumptions about variable types
invalid. Nothing can be done about it, but I don't consider this
critical, as "object-become!" is seldom used. And it's not hard in
general to confuse the scrutinizer by using various low-level hacks.
>> Perhaps we should get rid of object-become!; I'm not sure how useful
>> it is (only one egg uses it: protobuf), and it just causes trouble.
> An identical facility is used in Smalltalk when a class is redefined,
> to allow existing instances to conform to the new class definition.
> For each existing instance, a new instance is created, and then the new
> objects are made to replace the old.
It is also used in Smalltalk for object-persistence (filing in objects
that are represented by a "proxy" object).
"object-become!" is one of those features that are seldom used, but
for which no replacement exists: it allows changing an object without
changing its identity. The "utf8" egg uses this for modifying strings
in-place that grow in size due to "string-set!".