Differences

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

--- at:tutorial:objects [2007/07/09 21:13] – rewrote tvcutsem
+++ at:tutorial:objects [2007/07/10 21:52] – small tvcutsem
@@ Line 51: / Line 51: @@
 </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>
@@ Line 80: / Line 80: @@
 </code>
-===== Delegation and cloning =====
+===== Delegation and Cloning =====
-AmbientTalk features object inheritance or delegation. By means of delegation, an object can reuse and extend the defintion of another establishing a parent-child relationship. We identify two kinds of delegation relationships: **IS-A** and **SHARE-A**. 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).
+In order to support code reuse and modular extensions between objects, AmbientTalk features //delegation// (also known as object-based inheritance). By means of delegation, an object can reuse and extend the fields and methods of another object by establishing a so-called "parent-child" or "delegate-delegator" relationship.
-{{:at:tutorial:isaversussharea.png|:at:tutorial:isaversussharea.png}}
+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 (the difference between both is explained below).
-The following code shows how to extend objects with a **IS-A** relationship. It uses the ''extend: with:'' language construct.
+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>
-> def point3D := extend: point with: {
+def Point3D := extend: Point with: {
-    def z := 0;
+  def z := 0;
-    def sumOfSquares() {
+  def sumOfSquares() {
-      super^sumOfSquares() + z*z
+    super^sumOfSquares() + z*z
-    }
+  };
-  }
+}
 </code>
-The following code shows how to extend objects with a **SHARE-A** relationship. It uses the ''share: with:'' language construct.
+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.
+A **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.
 <code>
-> def point3D := share: point with: {
+def Collection := share: Enumerable with: {
-    def z := 0;
+  def elements := [];
-    def sumOfSquares() {
+  ...
-      super^sumOfSquares() + z*z
+}
-    }
-  }
 </code>
-===== Delegation and dynamic inheritance =====
+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 parent of an object is bound to a 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.
+The **IS-A** and **SHARES-A** delegation relationships differ in their semantics for cloning child objects. Whereas 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.
+===== Delegation and Dynamic Inheritance =====
+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 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.
+As any field in AmbientTalk objects, the ''super'' field can be dynamically modified.
 <code>
@@ Line 130: / Line 144: @@
 ===== 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>
-> 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>
-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>