_AddSlots: in programs

[jecel@lsi.usp.br (Jecel Mattos Assumpcao Jr)]

> Subject: Re: primitives 
> In-Reply-To: Your message of Wed, 30 Jan 91 19:41:05 -0500 
> Reply-To: Urs Hoelzle <hoelzle@cs.stanford.edu>
> Message-Id: <CMM.0.88.665431692.urs@>
> Status: RO
>
>> Are primitives like _RemoveSlots: and _AddSlots: going to be useable
>> within methods in the next release??  This would be cool, because it
>> would help with data inheritance.
>> 
>
> No (see the release message).  They do work in our current system
> (i.e. you can change objects while the program is running), but we
> want thing to stabilize a bit before putting them into a release.

I have been thinking about this as it seems to me that not being
able to modify objects at runtime makes it impossible to develop
a complete programming environment ( like Smalltalk's ) for Self.

There seems to be a language definition problem and a implementation
problem. What happens if modifying the object alters the lookup of
methods that are already on the stack? You could say that they 
should not be affected and that only messages sent from now on must
reflect the altered object. If Self were interpreted that would be
enough ( although multitasking complicates things ) but the problem
is that the compiler effectively caches lookups - code in methods
on the stack might have to be recompiled. Obviously, from the
message above, you have found a way around this problem but I can't
guess what the solution is.

A less general solution that would help me quite a bit would be
_CopyWithNewSlots: and _CopyWithoutSlots: primitives that would
create new objects modified as specified. Since these are new
objects, they cannot have any influence on already compiled methods
( and in particular, those on the stack(s) ). I believe these
primitives could be safely called from within any method.

--- Jecel ----