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/10 12:46] – fixed tvcutsemat:tutorial:objects [2007/07/10 22:00] – added tvcutsem
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 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>
at/tutorial/objects.txt · Last modified: 2013/05/17 20:23 by tvcutsem