at:tutorial:multiparadigm
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
at:tutorial:multiparadigm [2007/06/19 11:53] – * tvcutsem | at:tutorial:multiparadigm [2011/06/07 18:29] (current) – *minor tvcutsem | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== On Scoping, Closures, Methods and Messages ====== | ====== On Scoping, Closures, Methods and Messages ====== | ||
- | < | + | This tutorial chapter goes into a bit more detail on the interplay between AmbientTalk' |
- | + | ||
- | This tutorial chapter goes into a bit more detail on the subtle | + | |
===== Lexical Scope vs Object Scope ===== | ===== Lexical Scope vs Object Scope ===== | ||
Line 15: | Line 13: | ||
- Qualified access to a variable, e.g. '' | - Qualified access to a variable, e.g. '' | ||
- | These rules also hold for method invocation: the invocation '' | + | These rules also hold for method invocation: the invocation '' |
- | Probably the most important | + | The most important |
< | < | ||
Line 49: | Line 47: | ||
As can be derived from the rules defined above, the access to '' | As can be derived from the rules defined above, the access to '' | ||
- | < | + | < |
- | For many object-oriented programmers, | + | For many object-oriented programmers, |
+ | |||
+ | The confusion stems from the fact that many OO languages -- like Java -- make no distinction between both access forms. | ||
</ | </ | ||
Line 57: | Line 57: | ||
Second, the difference between early and late binding offers objects a very fine-grained control over what field and method accesses may be trapped and overridden by child objects. For example, in the code snippet above, '' | Second, the difference between early and late binding offers objects a very fine-grained control over what field and method accesses may be trapped and overridden by child objects. For example, in the code snippet above, '' | ||
- | ==== Nesting Objects ==== | + | The difference between unqualified and qualified slot access is also important to child objects. If a child object wants to invoke an inherited method of its parent object, it must invoke the method by means of a self-send. For example, consider AmbientTalk' |
+ | |||
+ | < | ||
+ | def myTest := extend: UnitTest with: { | ||
+ | def testSomething() { | ||
+ | self.assertEquals(1+1, | ||
+ | }; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | It is important that '' | ||
+ | |||
+ | ===== Nesting Objects | ||
AmbientTalk exploits its lexical scoping rules to the fullest extent by allowing as much program elements as possible to be nested. For example, it is possible to lexically nest objects within other objects, or even to nest functions within other functions. In this section, we describe how nested objects interact with the scoping rules presented above. | AmbientTalk exploits its lexical scoping rules to the fullest extent by allowing as much program elements as possible to be nested. For example, it is possible to lexically nest objects within other objects, or even to nest functions within other functions. In this section, we describe how nested objects interact with the scoping rules presented above. | ||
- | One of the most appealing use cases for nesting objects is that it allows a very secure kind of //sharing// between objects: all objects that are nested within another object have the privilege of all sharing the same lexical scope. This form of sharing is much more secure that sharing data via delegation, because the set of objects sharing the scope is statically fixed. In the [[www.erights.org|E language]], such nested objects are called [[http:// | + | ==== Facets ==== |
+ | |||
+ | One of the most appealing use cases for nesting objects is that it allows a very secure kind of //sharing// between objects: all objects that are nested within another object have the privilege of all sharing the same lexical scope. This form of sharing is much more secure that sharing data via delegation, because the set of objects sharing the scope is statically fixed. In the E language, such nested objects are called [[http:// | ||
As an example, the following code snippet defines a '' | As an example, the following code snippet defines a '' | ||
Line 85: | Line 99: | ||
The '' | The '' | ||
- | ==== Methods vs Closures | + | ==== Nesting and Delegation |
- | ==== External Methods ==== | + | Thanks to AmbientTalk' |
+ | |||
+ | < | ||
+ | def myWindow := extend: Window with: { | ||
+ | def title := " | ||
+ | def myButton := extend: Button with: { | ||
+ | // myButton can access lexical scope and | ||
+ | // its own object scope | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | It can sometimes happen that a nested object wants to invoke a method dynamically (rather than statically) on one of its outer objects. This is possible by aliasing '' | ||
+ | |||
+ | < | ||
+ | extend: UnitTest with: { | ||
+ | def testSomething() { | ||
+ | def theTest := self; | ||
+ | def inner := object: { | ||
+ | def compare(a, | ||
+ | theTest.assertEquals(a, | ||
+ | } | ||
+ | }; | ||
+ | inner.compare(1+1, | ||
+ | } | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | In the example above, writing '' | ||
+ | |||
+ | ===== Methods vs Closures ===== | ||
+ | |||
+ | As mentioned previously, AmbientTalk not only allows objects to be nested within other objects, but also allows functions to be nested within other functions. At this point, it becomes important to distinguish between // | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | Methods and closures are defined by means of the same syntax. They are distinguishable only by the context in which they are evaluated. For example: | ||
+ | |||
+ | < | ||
+ | def o := object: { | ||
+ | def x := 5; | ||
+ | def meth(y) { | ||
+ | def clo(z) { self.x + y + z } | ||
+ | }; | ||
+ | }; | ||
+ | > o.meth(2)(1); | ||
+ | >> 8 | ||
+ | </ | ||
+ | |||
+ | In the above example, '' | ||
+ | |||
+ | ==== Top-level Functions ==== | ||
+ | |||
+ | Top-level functions are actually methods in AmbientTalk. This is because all top-level code is treated as the initialization code of that file's module object. Hence, it is legal to use '' | ||
+ | |||
+ | ==== Block closures ==== | ||
+ | |||
+ | Block closures, as created by means of the syntax '' | ||
+ | |||
+ | ===== External Methods | ||
+ | |||
+ | It is possible to define methods and fields externally on an object. For example: | ||
+ | |||
+ | < | ||
+ | def calc := object: { | ||
+ | def add(x,y) { x+y }; | ||
+ | }; | ||
+ | def offset := 0; | ||
+ | def calc.sub(x, | ||
+ | </ | ||
+ | |||
+ | In this example '' | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | <note important> | ||
+ | There is one more difference between closures and external methods: next to the special treatment of '' | ||
+ | |||
+ | The rationale behind this decision is that '' | ||
+ | </ | ||
+ | |||
+ | <note warning> | ||
+ | External methods, while powerful, introduce many subtle issues in the language. Therefore, this feature may disappear from later releases of AmbientTalk. It is therefore wise to stay clear from using this feature. For an overview of the problem introduced by external field or method declarations, | ||
+ | </ | ||
===== First-class Methods ===== | ===== First-class Methods ===== | ||
+ | |||
+ | In AmbientTalk, | ||
+ | |||
+ | Methods become first-class when they are selected from existing objects. Because of the [[at: | ||
+ | |||
+ | < | ||
+ | def Math := object: { | ||
+ | def square(x) { x*x }; | ||
+ | }; | ||
+ | |||
+ | def squareClo := Math.& | ||
+ | > squareClo(2) | ||
+ | >> 4 | ||
+ | </ | ||
+ | |||
+ | Slot selection automatically lifts a method slot into a closure. The closure can subsequently be passed around as a stand-alone value. When the method closure is invoked, the original method is ran with '' | ||
+ | |||
+ | < | ||
+ | def Adder := object: { | ||
+ | def amount := 0; | ||
+ | def init(amnt) { | ||
+ | amount := amnt; | ||
+ | }; | ||
+ | def addTo(x) { | ||
+ | x + self.amount | ||
+ | }; | ||
+ | }; | ||
+ | > [1, | ||
+ | >> [2,3,4] | ||
+ | </ | ||
+ | |||
+ | The '' | ||
+ | |||
+ | The selection operator is also required when accessing lexically visible methods as first-class closures: | ||
+ | |||
+ | < | ||
+ | def o := object: { | ||
+ | def m() { ... }; | ||
+ | def grabTheMethod() { &m }; | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | Selection using ''&'' | ||
+ | |||
+ | < | ||
+ | def o := object: { | ||
+ | x := 5; | ||
+ | }; | ||
+ | def f := o.&x; | ||
+ | > f | ||
+ | >> <native closure: | ||
+ | > o.x := 6; f() | ||
+ | >> 6 | ||
+ | </ | ||
+ | |||
+ | In the same vein, one may select a mutator method for a field '' | ||
===== First-class Messages ===== | ===== First-class Messages ===== | ||
+ | |||
+ | Next to first-class methods, AmbientTalk also supports first-class messages. Messages are naturally represented as objects. They encapsulate a receiver, a selector and a table of actual arguments. AmbientTalk is definitely not the first language to treat messages as first-class citizens this way. For example, Smalltalk equally treats messages as objects. | ||
+ | |||
+ | The main difference with other languages is that AmbientTalk provides an expressive syntax to define first-class messages and to enable the sending of a first-class message to an object. In AmbientTalk, | ||
+ | |||
+ | < | ||
+ | def msg := .add(1,2); | ||
+ | > | ||
+ | >>< | ||
+ | > | ||
+ | >> | ||
+ | </ | ||
+ | |||
+ | This syntax is supported for all of AmbientTalk' | ||
+ | |||
+ | An AmbientTalk message supports the operation '' | ||
+ | |||
+ | < | ||
+ | calc <+ msg | ||
+ | </ | ||
+ | |||
+ | The ''< | ||
+ | |||
+ | First-class messages are often useful to implement [[http:// |
at/tutorial/multiparadigm.1182246817.txt.gz · Last modified: 2007/06/19 12:03 (external edit)