at:tutorial:objects
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
at:tutorial:objects [2007/07/04 16:25] – jorge | at:tutorial:objects [2013/05/17 20:23] (current) – updated tvcutsem | ||
---|---|---|---|
Line 4: | Line 4: | ||
In AmbientTalk, | In AmbientTalk, | ||
classes. Rather, they are either created ex-nihilo or by cloning | classes. Rather, they are either created ex-nihilo or by cloning | ||
- | and adapting existing objects, | + | and adapting existing objects, |
The following code illustrates the ex-nihilo creation of an object: | The following code illustrates the ex-nihilo creation of an object: | ||
< | < | ||
- | > def point := object: { | + | def Point := object: { |
- | def x := 0; | + | def x := 0; |
- | def y := 0; | + | def y := 0; |
- | def init(aX,aY) { | + | def init(aX,aY) { |
- | x := aX; | + | x := aX; |
- | y := aY; | + | y := aY; |
- | }; | + | }; |
- | def sumOfSquares() { x*x + y*y }; | + | def sumOfSquares() { x*x + y*y }; |
- | } | + | } |
</ | </ | ||
- | As all definitions in AmbientTalk, objects, fields and methods are defined using the **def** keyword. Fields are defined using a '' | + | The above code defines an // |
- | < | + | In the example above, the state of the point object is composed of '' |
- | AmbientTalk not only supports traditional canonical syntax (e.g. '' | + | |
+ | < | ||
+ | As already explained in the [[at: | ||
+ | |||
+ | For Smalltalk/ | ||
</ | </ | ||
- | |||
- | In the example above, the state of the '' | ||
===== Sending messages ===== | ===== Sending messages ===== | ||
Line 32: | Line 34: | ||
< | < | ||
- | > point.x | + | > Point.x |
- | >>2 | + | >>0 |
- | > point.sumOfSquares() | + | > Point.sumOfSquares() |
- | >>13 | + | >>0 |
</ | </ | ||
- | This code shows two messages sent to the '' | + | This code shows two messages sent to the point object defined above. The '' |
+ | |||
+ | Note that the " | ||
===== Cloning and instantiation ===== | ===== Cloning and instantiation ===== | ||
- | As said before in this section, AmbientTalk objects are created [[objects# | + | As noted above, AmbientTalk objects are created [[# |
< | < | ||
- | > def anotherPoint := point.new(2,3) | + | def anotherPoint := Point.new(2,3) |
</ | </ | ||
- | Every object understands the message '' | + | Every object understands the message '' |
- | AmbientTalk also provides a '' | + | < |
+ | > anotherPoint.x | ||
+ | >> 2 | ||
+ | > Point.x | ||
+ | >> 0 | ||
+ | > anotherPoint.x := 3 | ||
+ | >> nil | ||
+ | > Point.x | ||
+ | >> 0 | ||
+ | </ | ||
+ | |||
+ | < | ||
+ | AmbientTalk' | ||
+ | </ | ||
+ | |||
+ | AmbientTalk also provides a '' | ||
< | < | ||
- | > def clonedPoint := clone: | + | def clonedPoint := clone: |
+ | > clonedPoint.x | ||
+ | >> 0 | ||
+ | > clonedPoint.x := 2 | ||
+ | >> nil | ||
+ | > Point.x | ||
+ | >> 0 | ||
</ | </ | ||
- | ===== 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: | + | |
+ | In order to support code reuse and modular extensions between objects, AmbientTalk features // | ||
- | {{: | + | Delegation implies that, if a message is sent to an object, but that object has no definition for the message' |
+ | AmbientTalk distinguishes between **two kinds** of delegation relationships, | ||
- | The following code shows how to extend objects with a **IS-A** relationship. | + | An **IS-A** |
< | < | ||
- | > def point3D | + | def Point3D |
- | def z := 0; | + | def z := 0; |
- | def sumOfSquares() { | + | def sumOfSquares() { |
- | super^sumOfSquares() + z*z | + | super^sumOfSquares() + z*z; |
- | } | + | }; |
- | } | + | } |
</ | </ | ||
- | The following code shows how to extend objects with a **SHARE-A** relationship. It uses the '' | + | In this example, '' |
+ | |||
+ | 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 | ||
< | < | ||
- | > def point3D | + | def Collection |
- | def z := 0; | + | def elements |
- | def sumOfSquares() { | + | ... |
- | | + | } |
- | } | + | |
- | | + | |
</ | </ | ||
- | ===== Delegation and dynamic inheritance | + | In this code example, the '' |
- | The parent of an object is bound to a field named '' | + | |
+ | 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). | ||
+ | |||
+ | {{: | ||
+ | |||
+ | 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, | ||
+ | |||
+ | Because '' | ||
< | < | ||
- | > 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 connection := object: | ||
+ | def init() | ||
+ | | ||
+ | }; | ||
+ | | ||
+ | super := openConnection; | ||
+ | }; | ||
+ | def close() { | ||
+ | super := closedConnection; | ||
+ | }; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | In the above example, the '' | ||
+ | |||
+ | < | ||
+ | In AmbientTalk, | ||
+ | </ | ||
+ | |||
+ | ===== First-class Delegation ===== | ||
+ | |||
+ | AmbientTalk provides a special message-sending operator '' | ||
+ | |||
+ | < | ||
+ | def Enumerable := object: { | ||
+ | def collect: closure { | ||
+ | def c := self.new([]); | ||
+ | self.each: { |v| | ||
+ | c.add(closure(v)); | ||
}; | }; | ||
- | def close() { | + | |
- | | + | }; |
+ | }; | ||
+ | def Array := object: { | ||
+ | def elements := []; | ||
+ | | ||
+ | def add(v) { elements | ||
+ | def collect: closure { | ||
+ | Enumerable^collect: | ||
+ | }; | ||
+ | def each: clo { | ||
+ | 1.to: elements.length do: { |i| | ||
+ | clo(elements[i]); | ||
}; | }; | ||
- | } | + | }; |
+ | }; | ||
</ | </ | ||
- | <note important> | + | A message sent to an object using the '' |
- | In AmbientTalk, '' | + | |
+ | < | ||
+ | Array.add(1).add(2).add(3) | ||
+ | def c := Array.collect: | ||
+ | c.each: { |v| system.print(v)} // prints 234 | ||
+ | </ | ||
+ | |||
+ | Of course, the example above is a bit contrived: we could have just assigned '' | ||
+ | |||
+ | Having described the semantics of '' | ||
+ | |||
+ | < | ||
+ | def Point3D := extend: Point with: { | ||
+ | def z := 0; | ||
+ | def init(aX, aY, aZ) { | ||
+ | super^init(aX, | ||
+ | z := aZ; | ||
+ | }; | ||
+ | }; | ||
+ | </ | ||
+ | |||
+ | <note warning> | ||
+ | AmbientTalk, | ||
+ | |||
+ | Keep in mind, however, that '' | ||
</ | </ | ||
- | ===== First-class delegation | + | ===== Encapsulation |
- | AmbientTalk | + | |
+ | AmbientTalk | ||
< | < | ||
- | > def point3D := extend: point with: { | + | def makeBankAccount(balance) |
- | def z := 0; | + | |
- | def init(aX, aY, aZ) { | + | def deposit(amnt) { |
- | | + | |
- | | + | |
}; | }; | ||
} | } | ||
+ | } | ||
</ | </ | ||
- | A message sent to an object | + | Because the bank account |
- | <note important> | + | <code> |
- | The '' | + | > makeBankAccount(100).balance; |
- | </note> | + | >> |
+ | <obj:{super, | ||
+ | </code> | ||
- | ===== Encapsulation ===== | + | This pattern of creating objects by means of "constructor functions" |
- | In AmbientTalk, | + | |
< | < | ||
- | > def makeObject(hidden) { | + | def b := makeBankAccount(100); |
- | object: { | + | def b2 := b.new(); // shares its balance field with b! |
- | def foo() { /* use hidden | + | b.deposit(10); |
- | } | + | </code> |
+ | |||
+ | In order to prevent this kind of errors, it is considered best practice to override '' | ||
+ | |||
+ | < | ||
+ | def makeBankAccount(balance) { | ||
+ | object: { | ||
+ | def new(@args) { makeBankAccount(@args) }; | ||
+ | def deposit(amnt) { /* as before | ||
} | } | ||
+ | } | ||
</ | </ | ||
- | Due to the encapsulation of this object the following | + | By overriding '' |
+ | |||
+ | ===== Uniform Access ===== | ||
+ | |||
+ | AmbientTalk inherits from languages like Self, Eiffel and Ruby the property that field access is made indistinguishable from invoking a nullary method. This property is often referred to as the [[Wp> | ||
< | < | ||
- | > makeObject(5).hidden; | + | def o := object: { |
- | >>Lookup failure : selector hidden could not be found in | + | def x := 5 |
- | <object:5068254> | + | }; |
+ | > o.x | ||
+ | >> 5 | ||
+ | o := object: | ||
+ | def x() { 5 } | ||
+ | }; | ||
+ | > o.x | ||
+ | >> 5 | ||
</ | </ | ||
+ | |||
+ | Hence, the general rule is that '' | ||
+ | |||
+ | < | ||
+ | def o := object: { | ||
+ | def x := 5 | ||
+ | def xPlus1() { x + 1 } | ||
+ | }; | ||
+ | > o.xPlus1 | ||
+ | >> 6 | ||
+ | o := object: { | ||
+ | def x() { 5 } | ||
+ | def xPlus1() { x + 1 } | ||
+ | }; | ||
+ | > o.xPlus1 | ||
+ | >> 6 | ||
+ | </ | ||
+ | |||
+ | Note that the variable lookup '' | ||
+ | |||
+ | ==== UAP and closures ==== | ||
+ | |||
+ | One may wonder how the uniform access principle interacts with closures. That is, if '' | ||
+ | |||
+ | < | ||
+ | def o := object: { | ||
+ | def x := { 5 } | ||
+ | }; | ||
+ | > o.x | ||
+ | >> < | ||
+ | </ | ||
+ | |||
+ | The rationale is that '' | ||
+ | |||
+ | < | ||
+ | > o.x() | ||
+ | >> 5 | ||
+ | </ | ||
+ | |||
+ | When explicitly // | ||
+ | |||
+ | ==== UAP and Assignment ==== | ||
+ | |||
+ | In order to uphold the uniform access principle, special care is required with respect to assignment. If clients should be fully able to abstract over the implementation of slots as either fields or accessor methods, it should be possible to unify field assignment with mutator invocation. In AmbientTalk, | ||
+ | |||
+ | < | ||
+ | def realField := 5; | ||
+ | def o := object: { | ||
+ | def virtualField() { realField }; | ||
+ | def virtualField: | ||
+ | }; | ||
+ | > o.virtualField | ||
+ | >> 5 | ||
+ | > o.virtualField := 3 // interpreted as o.virtualField: | ||
+ | >> 3 | ||
+ | </ | ||
+ | |||
+ | In essence, assigning the field of an object is treated as a message send triggering a mutator method. Here's a more useful example of virtual fields: | ||
+ | |||
+ | < | ||
+ | def time := object: { | ||
+ | def seconds := 60; | ||
+ | // a field implicitly represents an accessor method seconds() | ||
+ | // and a mutator method seconds: | ||
+ | |||
+ | def minutes() { seconds / 60 }; | ||
+ | def hours() | ||
+ | |||
+ | def minutes: | ||
+ | seconds := mins * 60; mins | ||
+ | }; | ||
+ | def hours: | ||
+ | seconds := hours * 3600; hours | ||
+ | }; | ||
+ | }; | ||
+ | > time.minutes | ||
+ | >> 1 | ||
+ | > time.hours := 1 | ||
+ | >> 1 | ||
+ | > time.seconds | ||
+ | >> 3600 | ||
+ | > time.seconds := 180 | ||
+ | >> 180 | ||
+ | > time.minutes | ||
+ | >> 2 | ||
+ | </ | ||
+ | |||
+ | If no mutator method is defined, the field assignment will fail with a '' | ||
+ | |||
+ | < | ||
+ | AmbientTalk has no direct notion of '' | ||
+ | </ | ||
+ | |||
+ | The uniform access principle for assignments equally holds for lexically visible methods. In other words, the code '' | ||
+ | |||
+ | <note warning> | ||
+ | The parser currently does not support the explicit invocation of a mutator as a method or function (as in '' | ||
+ | </ |
at/tutorial/objects.1183559131.txt.gz · Last modified: 2007/07/04 16:27 (external edit)