I never been brave enough to venture into that dragon den (changing to
a class that changes the schema of the object -- only ever the same
exact schema), but I would think it would work fine in general. None
of the methods of A will be able to access the extra state appended to
the (former) B object in a normal sense, but perhaps with some of the
lower level (instVarNamed:[put:]), it could.
I'm glad to have stumbled on this since I've been using
#primitiveChangeClassTo: (myCustomSubclass basicNew), because I did
not know about adoptInstance:.
On Wed, Jun 13, 2018 at 3:55 PM Levente Uzonyi <[hidden email]> wrote:
> Hi All,
> I recently found a bug(?) with #adoptInstance: (primitive 160).
> If you create a variable class, let's call it A, and a subclass of it, B,
> where B has an instance variable called foo, then
> B adoptInstance: (A new: 1)
> will fail with error code #'bad receiver', which is fine, because B needs
> more slots than A, but
> A adoptInstance: (B new: 1)
> will succeed. The resulting object will have 2 indexable slots instead of
> 1, because the instance variable will be converted to an indexable slot.
> Is this the expected behavior? (primitive 115 does the same)