[squeak-dev] #adoptInstance: bug?

Chris Muller asqueaker at gmail.com
Mon Jun 18 05:15:32 UTC 2018

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 at 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

More information about the Squeak-dev mailing list