Referencing Objects: Self, Outer And This?

When deciding how objects should be referenced it was clear to me that the keyword self would be required because of its use to refer to the current object, and as the special return type. The keyword outer was also obviously required as evidenced by its need in Java and Java's horrible equivalent syntax. The this keyword was less obvious. It became clear that the language could be used without it, but also that it would serve a great convenience to programmers coming from a different view of object oriented programming. Below are the three solutions I proposed. They can be placed on a continuum from simple to complex.

1. Only self and outer:
   self is the object you are, yourself.
   outer is the object containing yourself.
   
   Pros: Simple and complete.
   Cons: Forces view of methods as objects, makes programmer work.


2. Simple self, outer and this:
   self is the object you are, yourself.
   this is the object containing yourself (self.outer).
   outer is the object containing an object object.outer, when written alone it is the object containing this (this.outer).
   
   Pros: Somewhat simple, provides help for those thinking of methods independent of objects.
   Cons: Confusing, this in a method and self in the object refer to the same thing.


3. Complex self, outer and this:
   self is the object you are, yourself.
   this is when used in:
   • an object body: the object (synonymous with self).
   • a pattern returning self (i.e. a class): the object created from the pattern (synonymous with self).
   • a pattern returning not self (i.e. a method): synonymous with self.outer.this (not legal), i.e.. recursive case.
   outer is the object containing an object object.outer, when written alone it is the object containing this (this.outer).
   
   Pros: Meets intuitive definition for those using methods distinct from objects view.
   Cons: Complex, may hinder view of methods as objects and does not sit well with my intuitions.

Resolution:

Went with number 3. The design precept of minimally complete argues for the less complex forms. However expressivity and readability support the more complex forms in this case. Particularly naturalness supports the third. This is only because of what most programers have been exposed to. As far as the language goals, the first Replace C, C++, Java, Eiffel, Simula, and Small Talk argues strongly for the third. This was what made the decision. If Opal was to replace those languages and be in popular use it must have the third standard form.

jwalker@cs.oberlin.edu