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 12:42] 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** relationshipIt uses the ''share: with:'' language construct. +
- +
-<code> +
-> def point3D := share: point with: { +
-    def z := 0; +
-    def sumOfSquares() { +
-      super^sumOfSquares() + z*+
-    } +
-  } +
-</code>+
  
 ===== Delegation and dynamic inheritance ===== ===== Delegation and dynamic inheritance =====
at/tutorial/objects.txt · Last modified: 2013/05/17 20:23 by tvcutsem