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 revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
at:tutorial:objects [2007/07/09 21:25] – explained tvcutsemat:tutorial:objects [2007/07/10 22:00] – added tvcutsem
Line 51: Line 51:
 </code> </code>
  
-Every object understands the message ''new'', which creates a clone (a shallow copy) of the receiver object and initializes the clone by invoking its ''init'' method with the arguments that were passed to new (''aX'' and ''aY'' in the example code). Hence, the ''init'' method plays the role of "constructor" for AmbientTalk objects. Hence, in the code above, ''anotherPoint'' shares its methods with its ''Point'' prototype, but it has its own set of fields:+Every object understands the message ''new'', which creates a clone (a shallow copy) of the receiver object and initializes the clone by invoking its ''init'' method with the arguments that were passed to new (''aX'' and ''aY'' in the example code). Hence, the ''init'' method plays the role of "constructor" for AmbientTalk objects. In the above code, ''anotherPoint'' shares its methods with its ''Point'' prototype, but it has its own set of fields:
  
 <code> <code>
Line 86: Line 86:
 Delegation implies that, if a message is sent to an object, but that object has no definition for the message's selector, then the message is //delegated// to a designated object (often called the //parent// or //delegate//). What is important to note here is that "delegating" a message is not the same as simply "forwarding" the message to the other object: delegating a message leaves the ''self'' pseudovariable unchanged to the //original// receiver of the message. Delegation implies that, if a message is sent to an object, but that object has no definition for the message's selector, then the message is //delegated// to a designated object (often called the //parent// or //delegate//). What is important to note here is that "delegating" a message is not the same as simply "forwarding" the message to the other object: delegating a message leaves the ''self'' pseudovariable unchanged to the //original// receiver of the message.
  
-AmbientTalk distinguishes between **two kinds** of delegation relationships,**IS-A** and **SHARES-A**, each denoting a different kind of object extension. An **IS-A** delegation relationship between two objects signifies that the child object "is-a" kind of parent object, with the implicit assumption that such a child object cannot exist without its parent. As an example, consider the following code (don't worry about the meaning of ''^'' yet):+AmbientTalk distinguishes between **two kinds** of delegation relationships,**IS-A** and **SHARES-A**, each denoting a different kind of object extension (the difference between both is explained below). 
 + 
 +An **IS-A** delegation relationship between two objects signifies that the child object "is-a" kind of parent object, with the implicit assumption that such a child object cannot exist without its parent. As an example, consider the following code (don't worry about the meaning of ''^'' yet):
  
 <code> <code>
Line 93: Line 95:
   def sumOfSquares() {   def sumOfSquares() {
     super^sumOfSquares() + z*z     super^sumOfSquares() + z*z
-  }+  };
 } }
 </code> </code>
  
-In this example, ''Point3D'' delegates+In this example, ''Point3D'' delegates any message it does not understand to ''Point''. The ''extend:with:'' construct creates a new object whose ''super'' slot is automatically set to the given parent object. The delegation relationship is **IS-A** because a ''Point3D'' is a kind of 2D ''Point'', and a ''z'' coordinate (conceptually) cannot exist without a corresponding ''x'' and ''y'' coordinate.
  
-These relationships define two different semantics for clonning child objects. Whereas clonning a **IS-A** child also clones its parent, **SHARE-A** child shares the parent of the cloned object (see the figure below).+**SHARES-A** relationship between two objects signifies that an object only delegates to another object purely for reasons of code or state sharing. The delegation link has no other semantics, and conceptually both parent and child can exist without one another.
  
 +The following code shows how to extend objects with a **SHARES-A** delegation relationship. It uses the ''share: with:'' language construct.
  
-{{:at:tutorial:isaversussharea.png|:at:tutorial:isaversussharea.png}}+<code> 
 +def Collection := shareEnumerable with
 +  def elements := []; 
 +  ... 
 +} 
 +</code>
  
 +In this code example, the ''Collection'' object delegates to ''Enumerable'' simply for inheriting useful methods such as ''inject:'' or ''collect:'' which are of general use to a collection object.
  
-The following code shows how to extend objects with a **IS-A** relationshipIt uses the ''extend: with:'' language construct.+The **IS-A** and **SHARES-A** delegation relationships differ in their semantics for cloning child objectsWhereas cloning an **IS-A** child also clones its parent, a **SHARES-A** child shares its parent object with the clonee (see the figure below).
  
 +{{:at:tutorial:isaversussharea.png|:at:tutorial:isaversussharea.png}}
  
 +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.
  
-The following code shows how to extend objects with a **SHARE-A** relationship. It uses the ''share: with:'' language construct.+===== Delegation and Dynamic Inheritance =====
  
-<code> +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 parentsdetermines the scope in which a 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.
-> def point3D := share: point with: { +
-    def z := 0; +
-    def sumOfSquares() +
-      super^sumOfSquares() + z*z +
-    } +
-  } +
-</code>+
  
-===== Delegation and dynamic inheritance ===== +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:
-The parent of an object is bound to a field named ''super''. The delegation chain defined by an object and its parent (or chain of parentsdetermines the scope in which the message is looked up. As any field in AmbientTalk objectsthe ''super'' field can be dynamically modified.+
  
 <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 close() { +def connection := object: 
-      super := closedConnection.new()+  def init() 
-    }; +    super := closedConnection; 
-  }+  }; 
 +  def open() { 
 +    super := openConnection; 
 +  }; 
 +  def close() { 
 +    super := closedConnection; 
 +  }; 
 +}
 </code> </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 important> <note important>
Line 141: Line 153:
  
 ===== First-class delegation ===== ===== First-class delegation =====
-AmbientTalk provides an explicit delegation operator ''^'' (the "caret" or "hat" symbol). The code below illustrates the use of the ''^'' operator in the implementation of the ''init'' method of the ''point3D'' object.+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 in the implementation of the ''init'' method of the ''point3D'' object.
  
 <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) { 
-      super^init(aX, aY); +    super^init(aX, aY); 
-      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 in the lexical scope of the message sender (''self'' is bound to the message sender).+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>
at/tutorial/objects.txt · Last modified: 2013/05/17 20:23 by tvcutsem