Differences

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

--- at:tutorial:objects [2007/07/10 22:00]
tvcutsem added
+++ at:tutorial:objects [2013/05/17 20:23]
tvcutsem updated
@@ Line 1: / Line 1: @@
-In this section, we explain how the object-oriented programming paradigm is implemented in AmbientTalk.
-===== Objects, fields and methods =====
-In AmbientTalk, objects are not instantiated from
-classes. Rather, they are either created ex-nihilo or by cloning
-and adapting existing objects, in the spirit of prototype-based programming such as in the SELF programming language. The definition of a prototypical object contains a number of fields and methods that represent the object's state and behaviour respectively.
-The following code illustrates the ex-nihilo creation of an object:
-<code>
-def Point := object: {
-  def x := 0;
-  def y := 0;
-  def init(aX,aY) {
-    x := aX;
-    y := aY;
-  };
-  def sumOfSquares() { x*x + y*y };
-}
-</code>
-The above code defines an //ex-nihilo// created point object and binds it to the variable ''Point''. The object itself does not carry a name (i.e. it is "anonymous"). Like all definitions in AmbientTalk, fields and methods are defined using the ''def'' keyword. Fields are defined using a ''def name := value'' syntax while methods are defined using a ''def name(parameters) {body}'' syntax.
-In the example above, the state of the point object is composed of ''x'' and ''y'' fields while its behaviour corresponds to the ''init'' and ''sumOfSquares'' methods.
-<note>
-As already explained in the [[at:tutorial:basic|basic programming]] part of the tutorial, AmbientTalk not only supports traditional canonical syntax (e.g. ''o.m(a,b,c)'') but also keyworded syntax (e.g. ''o.at: key put: value''). Keyworded syntax can be used both for method definitions and for message sends.
-For Smalltalk/Self programmers: note that a keyworded message send does require a message sending operator (like ''.'') in between the receiver and the message, which is different from Smalltalk and Self. As will be described in later chapters, AmbientTalk features more than one message sending operator, so the programmer must explicitly specify which one to use.
-</note>
-===== Sending messages =====
-In AmbientTalk, computation is expressed in terms of objects sending messages to one another. Messages are used to invoke the fields and methods of the objects.
-<code>
-> Point.x
->>0
-> Point.sumOfSquares()
->>0
-</code>
-This code shows two messages sent to the point object defined above. The ''x'' message acts as an accessor for the ''x'' field. The ''sumOfSquares'' message looks up the ''sumOfSquares'' method in the object and applies it.
-Note that the "prototypical" point object defined above can act as a stand-alone object. This is different from a class in a class-based language, which often requires the use of ''static'' fields or methods to be used stand-alone.
-===== Cloning and instantiation =====
-As noted above, AmbientTalk objects are created [[#Objects,_fields_and_methods|ex-nihilo]] or by cloning and adapting an existing object. The code below shows the instatiation of a new point object by //instantiating// the ''Point'' prototype:
-<code>
-def anotherPoint := Point.new(2,3)
-</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. In the above code, ''anotherPoint'' shares its methods with its ''Point'' prototype, but it has its own set of fields:
-<code>
-> anotherPoint.x
->> 2
-> Point.x
->> 0
-> anotherPoint.x := 3
->> nil
-> Point.x
->> 0
-</code>
-<note>
-AmbientTalk's object instantiation protocol closely corresponds to class instantiation in class-based languages. The major difference lies in the evaluation context of the ''init'' method: in a class-based language, the constructor is ran in the context of an empty object, freshly allocated from the class blueprint. In AmbientTalk, the ''init'' method is ran in the context of a shallow copy of an original object. Hence, in the ''init'' method, fields do not necessarily contain ''nil'' values: they have the value of the clonee. This can sometimes be useful to express the state of a clone as a delta w.r.t. the state of its clonee.
-</note>
-AmbientTalk also provides a ''clone:'' construct which only creates a clone of the receiver object without calling the ''init'' method ((As a matter of fact the ''new'' message desribed above does nothing more but invoking this construct and the ''init'' method subsequently.)).
-<code>
-def clonedPoint := clone: Point
-> clonedPoint.x
->> 0
-> clonedPoint.x := 2
->> nil
-> Point.x
->> 0
-</code>
-===== Delegation and Cloning =====
-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.
-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).
-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 z := 0;
-  def sumOfSquares() {
-    super^sumOfSquares() + z*z
-  };
-}
-</code>
-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 Collection := share: Enumerable 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 **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.
-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 objects. For example:
-<code>
-def openConnection := object: {
-  def send(msg) { ... };
-};
-def closedConnection := object: {
-  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 important>
-In AmbientTalk, ''self'' and ''super'' indicate the current object and its parent respectively. While the former corresponds to a language keyword the latter is just a field name of the object.
-</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 in the implementation of the ''init'' method of the ''point3D'' object.
-<code>
-def point3D := extend: point with: {
-  def z := 0;
-  def init(aX, aY, aZ) {
-    super^init(aX, aY);
-    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 with the ''self'' pseudovariable bound to the message sender.
-<note warning>
-The delegation operator does not have the same semantics as the dot notation. A 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.
-</note>
-===== Encapsulation =====
-In AmbientTalk, all fields and methods are "public" via selection. Still, 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.
-<code>
-> def makeObject(hidden) {
-    object: {
-      def foo() { /* use hidden */ }
-    }
-  }
-</code>
-Due to the encapsulation of this object the following instruction fails:
-<code>
-> makeObject(5).hidden;
->>Lookup failure : selector hidden could not be found in
-  <object:5068254>
-</code>

Ambient-Oriented Programming

User Tools

Site Tools

Differences

Page Tools