Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:introduction

Differences

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

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
at:introduction [2007/06/19 16:48]
tvcutsem 		at:introduction [2007/10/11 15:17]
tvcutsem *
Line 8: Line 8:
   * flexible: like Smalltalk, Self and Ruby, AmbientTalk embraces the use of elegant and expressive **block closures** to achieve a level of reusability far exceeding that of Java or similar languages lacking true closures.   * flexible: like Smalltalk, Self and Ruby, AmbientTalk embraces the use of elegant and expressive **block closures** to achieve a level of reusability far exceeding that of Java or similar languages lacking true closures.
   * event-driven: AmbientTalk has built-in support for **actor**-based concurrency, which operates based on entirely //asynchronous// and //event-driven// communication. No threads, no locks, no deadlock and no data-level race conditions!   * event-driven: AmbientTalk has built-in support for **actor**-based concurrency, which operates based on entirely //asynchronous// and //event-driven// communication. No threads, no locks, no deadlock and no data-level race conditions!
-  * distributed: AmbientTalk has built-in natives to make objects discover and talk to one another in a **peer-to-peer** manner across a TCP/IP network.+  * distributed: AmbientTalk has built-in language constructs to make objects discover and talk to one another in a **peer-to-peer** manner across a TCP/IP network.
   * **symbiotic**: built on top of the Java Virtual Machine, AmbientTalk exploits the Java reflection API to enable AmbientTalk objects to collaborate with Java objects. This enables reuse of existing Java libraries while not abandoning the dynamic programming style of AmbientTalk.   * **symbiotic**: built on top of the Java Virtual Machine, AmbientTalk exploits the Java reflection API to enable AmbientTalk objects to collaborate with Java objects. This enables reuse of existing Java libraries while not abandoning the dynamic programming style of AmbientTalk.
  
Line 132: Line 132:
  
 <code> <code>
-  defstripe InstantMessenger;+  deftype InstantMessenger;
   export: remoteInterface as: InstantMessenger;   export: remoteInterface as: InstantMessenger;
   whenever: InstantMessenger discovered: { |messenger|   whenever: InstantMessenger discovered: { |messenger|
Line 152: Line 152:
 </code> </code>
  
-The ''whenever:discovered:'' method takes a stripe and a one-argument closure as parameters. It invokes the closure every time a remote object exported as the given stripe is discovered. The first thing to do when a new messenger is discovered is to ask it for its name, by sending it the ''getName'' message. If the messenger was not previously discovered (i.e. its name is not in the buddy list), the messenger is added and the user is notified of the presence of the new buddy.+The ''whenever:discovered:'' method takes a type tag and a one-argument closure as parameters. It invokes the closure every time a remote object exported with (a subtype of) the given type tag is discovered. The first thing to do when a new messenger is discovered is to ask it for its name, by sending it the ''getName'' message. If the messenger was not previously discovered (i.e. its name is not in the buddy list), the messenger is added and the user is notified of the presence of the new buddy.
  
 Finally, notice how AmbientTalk allows you to deal with //partial failures//: you can register two kinds of //observers// on remote references which are triggered when the remote reference becomes disconnected (because of e.g. network partitions) and when it becomes reconnected. The second argument to ''when:disconnected:'' and ''when:reconnected:'' is a zero-arity closure. In this example, all we do is notify the user that a buddy when offline or came online. AmbientTalk's default semantics is to buffer messages sent to disconnected remote references internally, and to flush such messages if the remote reference should become reconnected. This provides the nice property that we can send messages to disconnected buddies and rest assured that the messages will arrive when the buddy rejoins the ad hoc network. Finally, notice how AmbientTalk allows you to deal with //partial failures//: you can register two kinds of //observers// on remote references which are triggered when the remote reference becomes disconnected (because of e.g. network partitions) and when it becomes reconnected. The second argument to ''when:disconnected:'' and ''when:reconnected:'' is a zero-arity closure. In this example, all we do is notify the user that a buddy when offline or came online. AmbientTalk's default semantics is to buffer messages sent to disconnected remote references internally, and to flush such messages if the remote reference should become reconnected. This provides the nice property that we can send messages to disconnected buddies and rest assured that the messages will arrive when the buddy rejoins the ad hoc network.
at/introduction.txt ยท Last modified: 2008/07/15 12:19 by tvcutsem

Page Tools

Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki