I came across a post by Jonathan Rees that I couldn't understand, but after several re-readings, it made sense, and it's an interesting point — the "all you can do is send a message" model, a.k.a the actor model, isn't enough.
First, some background, if you're not a programming language geek: many languages support message passing, which is like calling a method but different in that the receiver can define a catch all method that traps all unresolved method calls. Ruby, for example, calls this method_missing. This is different from Java where a class has to specify at compile time what methods it defines. Message passing is obviously more powerful, since it lets you implement things like proxies for RPC, access control or object persistence that can transparently decorate any object without knowing its interface.
The "all you can do is send a message" model rules out any other way of interacting with an object -- instanceof, object identity (that is, comparing pointers) and, of course, fields, which anyway can be looked at as synactic sugar for methods.
The only way out is to have an instrinsic notion type of an object as something visible to clients, independent of the behavior (methods). There must be a builtin instanceof operator or function as part of the language itself, and a way to compare pointers to see if they point to the same object.
Once you have this notion of the type of an object independent of its behavior (methods), methods don't need to be defined as part of the object; instead they can be defined as independent entities and hang off the object type. That is, an object is merely a map of key-value pairs, with an associated tag or type. Methods can be defined outside the object, and found based on the types of the arguments (multimethod dispatch). And you can build the language all the way up from that.