Peter Novak wrote:
We are working on prototypes in Squeak.
Henrik Gedenryd Henrik.Gedenryd@lucs.lu.se responded...
Great, finally someone's doing this. Let's hope you actually finish it. This is such a commendable effort that I think if you just succeed to convince us all that you're serious enough :) , you'll garner a good deal of support and interest from others--in part I am thinking of myself here; please tell us more about the whats and whys of your project!
I remember encouraging folks to try this, probably two years ago, saying one ought to be able to get fairly far in only a page or two. It wasn't the same thread, but about a month later someone (was it SMA? HMM?) came forward with just such a running sketch of prototypes. I seem not to have saved the code, but it's worth checking for others who may have done this already.
Regarding your question of classless methods, which now turns out to be the question of classless objects in general I suppose. (Forgive me if my answers are on the wrong level--I don't know how much you already know about these issues.)
We need something like executing SOME byteCode without having it installed in any class.
One quick and dirty approach used in Smalltalk is to use Behaviors directly, instead of full-blown classes. But this does give you an extra Behavior object per object. It will get you part of the way however.
This is the simplest approach - it is fully general and will run at full speed. The space overhead is not that bad -- one behavior and one methodDictionary per prototype. An upside is that it is also (obviously) simple to expand to siblings any time -- these are just multiple instances.
There is a somewhat niftier approach too: If you make the prototype (classless object) inherit from Behavior (hey--it has to have a class in the object header), then you can install the method directly into the object itself. I think there are some VM dependencies that tie methods to Behavior, but for the final answer you should consult Yoda himself. I may be wrong here, I don't know the primitives well enough, but you may not even need to install the CompiledMethod into a method dictionary. (Err, and welcome to the world of Behavior, ClassDescription, Metaclass, and friends--the dark side of the image.)
I'm not sure I would characterize this as "nifty", but I like your enthusiasm. It would not be as simple as you say, because if you make it *be* a subclass of behavior, the methods that you install in it will only affect its *instances* of which there are none. I can imagine a severe hack (involving forward become) that would redirect the class pointer of this object at itself, thus allowing it to get behavior from itself. That would indeed be nifty but it might break some very important things (see (*) below).
My feeling about such experiments is that it's best to do them in the most natural way for the host system (in Squeak this means using a behavior for each prototype), and then when it's all working you can step back from it and look at the statistics of the system and make some rational design decisions about what might make it better in terms of speed, space and understandability.
. . .
The browser code and logic is very hard-wired to the current class system and inheritance scheme.
This is true. That is why Players are classes and not just behaviors right now. I just makes it a lot easier to play with them and debug them. Again, it may be simplest to waste some space to get it all going conveniently, and the decide how to simplify the structures after it all works.
But to approach a more final answer to your question about prototypes & methods, you must consider how inheritance (or what you choose to call it--delegation etc.) should work with your prototypes. That is the real issue.
Henrik is right here. Yet another reason to do something simple to get started until you know what you really want.
Have fun, and good luck.
- Dan
(*) It *might* work to make a subclass of behavior, and then forward-become its class (a metaclass) into itself. That metaclass should get reclaimed then, because nothing would point at it. The object we were left with would be an instance of itself, so messages would get looked up first in itself, then in its superclass, etc. A crucial detail is that an object's format in memory is described by the format field of its class, so very soon after the become, you must store into the format word, the value that used to be in the format work of its prior (meta-) class.
(I would try this right now, but I don't want to take the fun away from someone else ;-).