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