User Tools

Site Tools


at:tutorial:objects

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
at:tutorial:objects [2007/07/10 12:46]
tvcutsem fixed
at:tutorial:objects [2013/05/17 20:23] (current)
tvcutsem updated
Line 94: Line 94:
   def z := 0;   def z := 0;
   def sumOfSquares() {   def sumOfSquares() {
-    super^sumOfSquares() + z*z+    super^sumOfSquares() + z*z;
   };   };
 } }
Line 120: Line 120:
 This cloning semantics reinforces the semantics of **IS-A** as promoting a unique link between a parent and a child object. **IS-A** delegation most closely corresponds to class-based inheritance. This cloning semantics reinforces the semantics of **IS-A** as promoting a unique link between a parent and a child object. **IS-A** delegation most closely corresponds to class-based inheritance.
  
-===== Delegation and dynamic inheritance ===== +===== Delegation and Dynamic Inheritance ===== 
-The parent of an object is bound to field named ''super''. The delegation chain defined by an object and its parent (or chain of parents) determines the scope in which the message is looked up. As any field in AmbientTalk objects, the ''super'' field can be dynamically modified.+ 
 +In AmbientTalk, all objects delegate messages they cannot understand to the object stored in their field named ''super''. The delegation chain defined by an object and its parent (or chain of parents) determines the scope in which message is looked up. For ex-nihilo created objects, like the ''Point'' object defined previously, the ''super'' slot is by default set to ''nil''. When a message is finally delegated all the way up to ''nil'', ''nil'' informs the original receiver of the message of the failed lookup, which by default reports the error by means of a ''SelectorNotFound'' exception. 
 + 
 +Because ''super'' is a regular field of an AmbientTalk object (it is just installed by default), it can be dynamically modified, giving rise to //dynamic inheritance//: the ability of objects to change their object inheritance hierarchy at runtime. The SELF language has demonstrated how this language feature can be put to good use for modeling stateful objectsFor example:
  
 <code> <code>
-def openConnection := object: {...}; +def openConnection := object: 
-def closedConnection := object: {...}; +  def send(msg) { ... }; 
-def connection := object: { +}; 
-    def open() { +def closedConnection := object: 
-      super := openConnection.new();+  def send(msg) { ... }; 
 +}; 
 +def connection := object: 
 +  def init() 
 +    super := closedConnection; 
 +  }; 
 +  def open() { 
 +    super := openConnection
 +  }; 
 +  def close() { 
 +    super := closedConnection; 
 +  }; 
 +
 +</code> 
 + 
 +In the above example, the ''connection'' object can be in an "open" or "closed" state. Rather than implementing the state-specific behaviour of e.g. the ''send'' method by means of a state variable and an ''if''-test, state-specific methods are implemented in dedicated objects which are dynamically assigned as the parent of the ''connection'' object when it changes state. When ''connection.send(msg)'' is evaluated, the ''send'' message is delegated to the parent, resulting in the application of the method in the correct state. 
 + 
 +<note> 
 +In AmbientTalk, ''self'' and ''super'' indicate the receiver object and the parent respectively. However, ''self'' is a pseudovariable: it is a special keyword, not a variable that can be assigned to. ''super'' on the other hand, denotes a regular field in an object. This is a significant difference with respect to many other object-oriented languages who also treat ''super'' as a special keyword. There is, however, a reason for this special treatment of ''super'': "super-sends". The repercussions of AmbientTalk's treatment of ''super'' on "super-sends" is discussed below. 
 +</note> 
 + 
 +===== First-class Delegation ===== 
 + 
 +AmbientTalk provides a special message-sending operator ''^'' (the "caret" or "hat" symbol) to express the //explicit// delegation of a message to an object. The code below illustrates the use of the ''^'' operator: 
 + 
 +<code> 
 +def Enumerable := object: { 
 +  def collect: closure { 
 +    def c := self.new([]); 
 +    self.each: { |v| 
 +      c.add(closure(v));
     };     };
-    def close() { +    c; 
-      super := closedConnection.new();+  }; 
 +}; 
 +def Array := object: { 
 +  def elements := []; 
 +  def init(a) { elements := a; }; 
 +  def add(v) { elements := elements + [v]; self }; 
 +  def collect: closure { 
 +    Enumerable^collect: closure; 
 +  }; 
 +  def each: clo { 
 +    1.to: elements.length do: { |i| 
 +      clo(elements[i]);
     };     };
-  }+  }
 +};
 </code> </code>
  
-<note important> +A message sent to an object using the ''^'' symbol (e.g. to the ''Enumerable'' object in the example above) will start the method lookup in this object and execute the method body with the ''self'' pseudovariable **left unchanged** to the message sender. In the code example abovewhen ''collect:'' is invoked on an ''Array'' object, the array object //delegates// the message to the ''Enumerable'' object. As such, method lookup starts in ''Enumerable'', finds the method there, and then invokes it with ''self'' left bound to the ''Array'' object. Hence, the ''self.each:'' send in the ''Enumerable'' object uses ''Array'''s definition of ''each:'' to generate the elements in the collection.
-In AmbientTalk, ''self'' and ''super'' indicate the current object and its parent respectivelyWhile the former corresponds to a language keyword the latter is just a field name of the object. +
-</note>+
  
-===== First-class delegation ===== +<code> 
-AmbientTalk provides special message-sending operator ''^'' (the "caretor "hat" symbol) to express the //explicit// delegation of a message to an object. The code below illustrates the use of the ''^'' operator in the implementation of the ''init'' method of the ''point3D'' object.+Array.add(1).add(2).add(3) 
 +def c :Array.collect: { |v| v+1 } 
 +c.each: { |v| system.print(v)} // prints 234 
 +</code> 
 + 
 +Of course, the example above is bit contrived: we could have just assigned ''Enumerable'' as the parent of ''Array'' such that we would not even have to write the "delegating''collect:'' method in ''Array''. However, what the explicit ''^'' delegation operator allows is the expression of patterns resembling //multiple inheritance// where some requests are delegated to one object, while other methods can be delegated to other objectsExplicit delegation enables the expression of delegation patterns which would be awkward or difficult to express using only single (delegation-based) inheritance. In [[:at:tutorial:modular#objects_as_traits|a later chapter]], we will show how ''^'' forms the basis for advanced //trait composition//
 + 
 +Having described the semantics of ''^'', we can now turn our attention to "super-sends". In AmbientTalk, a traditional "super-send" (ala Java or Smalltalk) is expressed as explicit delegation to the ''super'' object. For example, here is how to properly initialize parent objects from child objects:
  
 <code> <code>
-def point3D := extend: point with: {+def Point3D := extend: Point with: {
   def z := 0;   def z := 0;
   def init(aX, aY, aZ) {   def init(aX, aY, aZ) {
Line 150: Line 200:
     z := aZ;     z := aZ;
   };   };
-}+};
 </code> </code>
- 
-A message sent to an object using the ''^'' symbol (e.g. to the parent object in the example above) will start the method lookup in this object (and its parents) and then execute the method body with the ''self'' pseudovariable bound to the message sender. 
  
 <note warning> <note warning>
-The delegation operator does not have the same semantics as the dot notationA message sent to ''super'' using the dot notation will not only start the method lookup in the object bound the ''super'' field but also bind the ''self'' pseudo variable to this object.+AmbientTalk, unlike many other OO languages (including Java and Smalltalk) does not treat ''super.m(foo)'' as a special constructBecause AmbientTalk regards ''super'' as a regular field name, and because it distinguishes invocation from delegation by means of ''.'' vs ''^'', super-sends can be expressed without any special additions as ''super^m(foo)''
 + 
 +Keep in mind, however, that ''super.m(foo)'' is //not// a "super-send" in the traditional sense of the word. Rather, it is a method invocation on ''super'', changing the value of ''self'' in ''m'' to refer to ''super''.
 </note> </note>
  
 ===== Encapsulation ===== ===== Encapsulation =====
-In AmbientTalk, all fields and methods are "public" via selectionStill, a field or method can be made "private" by means of lexical scoping. The following code shows the definition of an object inside the definition of a function. The fields and methods of this object cannot be accessed directly from outside the funuction.+ 
 +AmbientTalk has no notion of "visibility modifiers" for fields or methods. All fields and methods of an object are considered "public"Nevertheless, a field or method can be made "private" to a scope by means of lexical scoping (a technique sometimes referred to as [[http://www.erights.org/elib/capability/ode/ode-objects.html|lambda abstraction]]). The following code shows the definition of an object inside the definition of a function. Although all of the object'fields and methods are public, the object can make use of lexically visible fields and methods of outer objects or functions which are not simply accessible "from the outside":
  
 <code> <code>
-def makeObject(hidden) { +def makeBankAccount(balance) { 
-    object: { +  object: { 
-      def foo() { /* use hidden */ } +    def deposit(amnt) { 
-    }+      balance := balance + amnt; 
 +      "ok" 
 +    };
   }   }
 +}
 </code> </code>
  
-Due to the encapsulation of this object the following instruction fails:+Because the bank account object encapsulates its ''balance'' in its private, lexical scope, the following code fails:
  
 <code> <code>
-makeObject(5).hidden+makeBankAccount(100).balance
->>Lookup failure : selector hidden could not be found in  +>>Lookup failure : selector balance could not be found in  
-  <object:5068254>+  <obj:{super,super:=,deposit}>
 </code> </code>
 +
 +This pattern of creating objects by means of "constructor functions" rather than by cloning and instantiating prototypes is often very useful in its own right. However, when creating objects that use their lexical scope to hold their state, be aware of the following issue when you mix object creation via instantiation and object creation via cloning: clones //share// their lexical scope! Hence, given a bank account object ''b'', the following leads to erroneous behaviour:
 +
 +<code>
 +def b := makeBankAccount(100);
 +def b2 := b.new(); // shares its balance field with b!
 +b.deposit(10); // affects b2 as well!
 +</code>
 +
 +In order to prevent this kind of errors, it is considered best practice to override ''new'' for objects that should be solely defined by means of constructor functions, as follows:
 +
 +<code>
 +def makeBankAccount(balance) {
 +  object: {
 +    def new(@args) { makeBankAccount(@args) };
 +    def deposit(amnt) { /* as before */ };
 +  }
 +}
 +</code>
 +
 +By overriding ''new'' and calling the constructor function, this code ensures that code such as ''aBankAccount.new(10)'' will result in a proper new bank account object with its own private lexical scope to store its state.
 +
 +===== Uniform Access =====
 +
 +AmbientTalk inherits from languages like Self, Eiffel and Ruby the property that field access is made indistinguishable from invoking a nullary method. This property is often referred to as the [[Wp>Uniform_access_principle|uniform access principle]], a term coined by Bertrand Meyer. In essence, the principle allows designers of abstractions to freely change public fields into methods that take no arguments, and vice versa **without** requiring changes to client code that uses the abstraction. The following example illustrates the essence of the UAP:
 +
 +<code>
 +def o := object: {
 +  def x := 5
 +};
 +> o.x
 +>> 5
 +o := object: {
 +  def x() { 5 }
 +};
 +> o.x
 +>> 5
 +</code>
 +
 +Hence, the general rule is that ''o.x'' is equivalent to ''o.x()''. Importantly, this principle also holds for //lexical// resolution of variables, rather than dynamic resolution via message sending. For example:
 +
 +<code>
 +def o := object: {
 +  def x := 5
 +  def xPlus1() { x + 1 }
 +};
 +> o.xPlus1
 +>> 6
 +o := object: {
 +  def x() { 5 }
 +  def xPlus1() { x + 1 }
 +};
 +> o.xPlus1
 +>> 6
 +</code>
 +
 +Note that the variable lookup ''x'' is treated as ''x()'' when the variable refers to a lexically visible //method// rather than a //field//. This is useful because it allows changing fields into methods or vice versa without even affecting nested objects making use of the abstraction.
 +
 +==== UAP and closures ====
 +
 +One may wonder how the uniform access principle interacts with closures. That is, if ''x'' is a field whose value is a block closure, does ''o.x'' return the closure or does it implicitly apply that closure with zero arguments, as it does if ''x'' were bound to a method? The answer is no:
 +
 +<code>
 +def o := object: {
 +  def x := { 5 }
 +};
 +> o.x
 +>> <closure:lambda>
 +</code>
 +
 +The rationale is that ''x'' is bound to a field, so performing ''o.x'' simply selects the value from the field. However, what happens if we evaluate ''o.x()'' instead?
 +
 +<code>
 +> o.x()
 +>> 5
 +</code>
 +
 +When explicitly //applying// the ''x'' field, the interpreter //does// execute the block closure stored in ''x''. If the interpreter would not behave in this way, but rather have ''o.x()'' return the closure as well, then the programmer would be required to write ''(o.x)()'' to apply the closure, which is a bit clumsy. In essence, the rule remains simple: code of the form ''o.x'' either returns the value of a //field// ''x'' or executes a //method// ''x''. Whether or not the field contains a closure does not change the semantics.
 +
 +==== UAP and Assignment ====
 +
 +In order to uphold the uniform access principle, special care is required with respect to assignment. If clients should be fully able to abstract over the implementation of slots as either fields or accessor methods, it should be possible to unify field assignment with mutator invocation. In AmbientTalk, mutators are methods whose name ends with '':=''. These methods take one argument and can be invoked by means of the field assignment syntax:
 +
 +<code>
 +def realField := 5;
 +def o := object: {
 +  def virtualField() { realField };
 +  def virtualField:=(v) { realField := v }; 
 +};
 +> o.virtualField
 +>> 5
 +> o.virtualField := 3 // interpreted as o.virtualField:=(3)
 +>> 3
 +</code>
 +
 +In essence, assigning the field of an object is treated as a message send triggering a mutator method. Here's a more useful example of virtual fields:
 +
 +<code>
 +def time := object: {
 +  def seconds := 60;
 +  // a field implicitly represents an accessor method seconds()
 +  // and a mutator method seconds:=(v)
 +
 +  def minutes() { seconds / 60 };
 +  def hours()   { seconds / 3600 };
 +
 +  def minutes:=(mins) {
 +    seconds := mins * 60; mins
 +  };
 +  def hours:=(hours) {
 +    seconds := hours * 3600; hours
 +  };
 +};
 +> time.minutes
 +>> 1
 +> time.hours := 1
 +>> 1
 +> time.seconds
 +>> 3600
 +> time.seconds := 180
 +>> 180
 +> time.minutes
 +>> 2
 +</code>
 +
 +If no mutator method is defined, the field assignment will fail with a ''SelectorNotFound'' exception.
 +
 +<note>
 +AmbientTalk has no direct notion of ''final'' or constant variables. However, if read-only access to a field for clients is required, one can simply implement the "field" as an accessor method. In this way, the method can be invoked as if it were a field, but any attempt to assign the field will fail because no corresponding mutator has been defined.
 +</note>
 +
 +The uniform access principle for assignments equally holds for lexically visible methods. In other words, the code ''x := 5'' is interpreted as a //function call// ''x:=(5)'', just as the assignment ''o.x := 5'' is interpreted as a //message send// ''o.x:=(5)''.
 +
 +<note warning>
 +The parser currently does not support the explicit invocation of a mutator as a method or function (as in ''o.m:=(v)''). To invoke a mutator, always use the field assignment syntax (as in ''o.m := v'').
 +</note>
at/tutorial/objects.1184064374.txt.gz · Last modified: 2007/07/10 21:52 (external edit)