private vs public

So my objects have two collections (maps to be precise); the private slots and the public interface.

The private slots can be any object. They could therefore be used for private methods, or anonymous functions which are then used within a method (this reduces the overhead of creating anonymous functions everytime we use them), or even constants within the object (eg numbers and strings).

Using constants in this way means we don't need to provide the object with any knowledge of those constant's factories etc except when the object is constructed. This is a benefit to the image/deserialization approach to application development (more about this later).

While I say 'private', 'protected' may be a better word as they are visible to all children of the current object. They are also 'updatable', but only from the current object's point of view, the original value on the original object does not change.

The public interface is made up of only methods - messages that can be sent to the object by any other object that has a reference.

It is obviously imperative that objects have this split from a security point of view, but they also help with data/implementation hiding, a very important part of modular development.

The problem with Javascript (and I think this is what Bracha was getting at) is that everything in the object is public. Now you can use patterns as defined by Crockford, but these are a bit kludgy, a bit nasty in terms of creating a shit load of objects (all those continuations, for each and every object) and hence lead to multiple approaches to object creation.