Differences

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

--- at:tutorial:actors [2007/05/15 19:35] – * tvcutsem
+++ at:tutorial:actors [2007/06/19 16:14] – * tvcutsem
@@ Line 34: / Line 34: @@
 So what exactly is a far reference to an object? The terminology stems from the E language: it is an object reference that refers to an object hosted by another actor. The main difference between regular object references and far references is that regular references allow direct, synchronous access to an object, while far references disallow such access. This is enforced by the kind of messages that these references can carry, as will be explained below.
-Note that, if the object referred to by a far reference is striped with one or more stripes, the far reference itself is striped with the same stripes. Hence, an object located on a remote actor can be tested for its stripes //synchronously//, there is no need to communicate with the remote actor, as the far reference itself includes stripe information.
+Note that, if the object referred to by a far reference is tagged with one or more type tags, the far reference itself is tagged with the same type tags. Hence, an object located on a remote actor can be tested for its types //synchronously//, there is no need to communicate with the remote actor, as the far reference itself includes type tag information.
 ===== Asynchronous Message Sending =====
@@ Line 107: / Line 107: @@
   };
 };
->><object:15603573[<stripe:Isolate>]>
+>><object:15603573[<type tag:Isolate>]>
 </code>
-The ''isolate:'' primitive is actually syntactic sugar for the creation of an object that is automatically striped with the ''/.at.stripes.Isolate'' stripe. Any object that is striped with this stripe is treated as an isolate. If you are a Java programmer, you can best compare this behaviour to having to implement the ''java.io.Serializable'' interface to make a class's instances serializable.
+The ''isolate:'' primitive is actually syntactic sugar for the creation of an object that is automatically tagged with the ''/.at.types.Isolate'' type tag. Any object that is tagged with this type tag is treated as an isolate. If you are a Java programmer, you can best compare this behaviour to having to implement the ''java.io.Serializable'' interface to make a class's instances serializable.
 An isolate differs from a regular object as follows:
@@ Line 245: / Line 245: @@
 </code>
-Or, you can specify a stripe to only catch specific exceptions:
+Or, you can specify a type tag to only catch specific exceptions:
 <code>
@@ Line 276: / Line 276: @@
 When the future for ''<-add(1,2)'' becomes resolved with ''sum'', the ''fut'' future will be resolved with the future for the ''<-add(sum,3)'' message. When that message finally returns yet another sum, that sum will become the value of ''fut''.
-==== Futures and Striped Messages ====
+==== Futures and Annotated Messages ====
-As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking ''enableFutures(true)'' makes asynchronous sends return a future by default. Invoking ''enableFutures(false)'' returns ''nil'' by default. No matter how you enabled futures, you can always override the default setting by explicitly //annotating// the message send itself by means of two stripes exported by the futures module, as explained below.
+As previously explained, there are two modes for enabling futures in AmbientTalk. Invoking ''enableFutures(true)'' makes asynchronous sends return a future by default. Invoking ''enableFutures(false)'' returns ''nil'' by default. No matter how you enabled futures, you can always override the default setting by explicitly //annotating// the message send itself by means of two type tags exported by the futures module, as explained below.
-When a message send is striped with the ''OneWayMessage'' stripe, it will never attach a future to the message. This is primarily useful if you have enabled futures by default, but want to send a one-way message requiring no result. In this case, simply send the message as follows:
+When a message send is annotated with the ''OneWayMessage'' type tag, it will never attach a future to the message. This is primarily useful if you have enabled futures by default, but want to send a one-way message requiring no result. In this case, simply send the message as follows:
 <code>
@@ Line 286: / Line 286: @@
 </code>
-When a message send is striped with the ''FutureMessage'' stripe, a future is attached to the message, but //only if futures have been enabled//! This is primarily useful if you have enabled futures, but not by default, because you don't want to incur the overhead of future-type message sends on each of the messages sent. In cases where futures become useful, simply send the message as follows:
+When a message send is annotated with the ''FutureMessage'' type tag, a future is attached to the message, but //only if futures have been enabled//! This is primarily useful if you have enabled futures, but not by default, because you don't want to incur the overhead of future-type message sends on each of the messages sent. In cases where futures become useful, simply send the message as follows:
 <code>