Bloody Gilad is right again!

So I've been grappling with the problem of security with the objects in DynamOS - how does one ensure that packages can't modify the objects passed into them, with global ramifications? Well the crux of the problem is outlined by Gilad in Objects aren't Hashes.

Now I have been treating objects as hashes, and in Javascript and so on this works fine, but it means that you can do all kinds of nasty hacks right into the most fundamental classes - and these hacks affect the entire VM. Gilad points out that an object really needs to have some kind of encapsulation - and a self reference.

The encapsulation means that there are parts of the object that can't be accessed by the outside world. There are some aspects that can't be manipulated by the outside world unless you have special permission (eg you have a reflection/mirror capability or the object exposes those abilities to you).

DynamOS has Slots, which are the internal attributes of an object, and Functions, which are the interface to the rest of the world. I have been grappling with how to have the functions refer to slots that don't have public accessors (eg you are writing the public accessor...). Because everything is a message send, what message can you send since all messages are in the functions list...

Now Gilad points out why this doesn't work - because there must be a separation between the interface and the implementation/data abstraction. In Newspeak he achieves this by having classes, and within a class you can send a message that refers to the internal slot because that slot is within your context.

So that lead me to an 'aha' moment; maybe I could use the function definition in DynamOS as a kind of object definition, but with a different 'setter' mechanism.

In a function, when you set a value, dynamos will search for the slot by symbol, and when it finds it, it will set it the the specified value. But in an object we want to do any setting on the current object. In this way we have prototypical inheritance.

I hope (and I still have to think a bit harder about this) that by simply changing this mechanism that I can achieve Gilads separation with no change to my opcodes, just a small addition to the VM object (createObjectWith: opcodes andArguments: arguments).

This doesn't stop someone from adding a 'createInstance' method within their object - and hence creating a class. It also doesn't stop someone from exposing the slot CRUD mechanism. But it does mean that objects can't ordinarily have their basic makeup changed by anyone, willy nilly.