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:.
- Chris On Wed, Jun 13, 2018 at 3:55 PM Levente Uzonyi leves@caesar.elte.hu 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)
Levente