On Oct 25, 2005, at 6:32 AM, Tony Garnock-Jones wrote:

> Colin Putney wrote:
>
>> I second this idea. I did the same sort of thing when fooling  
>> around with different ways of representing code using packages.  
>> It's surprisingly easy, and a great way to experiment with stuff  
>> that would be really difficult to do to the core system without  
>> breaking it, at least temporarily.
>>
>
> Wow! I'd love to hear more detail about how this kind of thing is  
> done. Where are the main gotchas? Where does one *start*?

Well, getting started is easy. Just develop your new classes as  
ususal. The tricky bits only come when you want to create instances  
of them. In my case, I used a class name prefix of CM to distinguish  
my sandbox from the core system. I just implemented CMBehavior,  
CMClass, CMMetaclass and so on. Then I wrote a little importer that  
would first create the core sandbox - nil, ProtoObject, Object and  
their metaclasses - and then import a set of packages into the sandbox.

Gotchas to look out for:

- behaviors must have the following as the first three instance  
variables: "superclass methodDictionary format".

- every object must be able to respond to at least one method,  
#doesNotUnderstand: if you try to send a message to an object with no  
methods at all, the VM will shut down in disgust.

- there's an anomaly where the metaclass hierarchy "wraps around" and  
becomes normal classes. For example, have a look at the difference  
between "ProtoObject superclass" and "ProtoObject class superclass".


And that's it. Have fun!

Colin