Ambient-Oriented Programming

User Tools

Site Tools

Trace:
at:tutorial:actors

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
Next revisionBoth sides next revision
at:tutorial:actors [2008/03/13 16:23] – * tvcutsemat:tutorial:actors [2008/08/01 14:44] – * tvcutsem
Line 26: Line 26:
   };   };
 }; };
->><far ref to:<object:1555668>>+>><far ref:behaviour of <actormirror:9501984>>
 </code> </code>
  
Line 112: Line 112:
   };   };
 }; };
->><object:15603573[<type tag:Isolate>]>+>><obj:{super,super:=,re,re:=,im,im:=,...}[Isolate]>
 </code> </code>
  
Line 196: Line 196:
  
 The first statement imports the futures module into the current lexical scope. This enables you as a developer to use some additional language constructs exported by the futures module, as will be explained later. The second statement enables the futures behaviour, causing any asynchronous message send to return a future rather than ''nil''. If ''false'' is passed to the call to ''enableFutures'', only messages marked explicitly as a ''FutureMessage'' will return a future. The first statement imports the futures module into the current lexical scope. This enables you as a developer to use some additional language constructs exported by the futures module, as will be explained later. The second statement enables the futures behaviour, causing any asynchronous message send to return a future rather than ''nil''. If ''false'' is passed to the call to ''enableFutures'', only messages marked explicitly as a ''FutureMessage'' will return a future.
 +
 +More information pertaining to the API of the futures language module can be found in the [[:at:tutorial:appendix#futures_and_multifutures|appendix]].
  
 ==== Working with Unresolved Futures ==== ==== Working with Unresolved Futures ====
Line 204: Line 206:
  
 The solution proposed in the [[http://www.erights.org|E language]], and adopted in AmbientTalk, is to disallow direct access to a future by any object. Instead, objects may **only** send **asynchronous** messages to a future object. This enables the future to temporarily buffer such messages until its resolved value is known. The net effect of this solution is that futures actually can be "chained", forming asynchronous //pipelines// of messages, as will be illustrated in the next section. The solution proposed in the [[http://www.erights.org|E language]], and adopted in AmbientTalk, is to disallow direct access to a future by any object. Instead, objects may **only** send **asynchronous** messages to a future object. This enables the future to temporarily buffer such messages until its resolved value is known. The net effect of this solution is that futures actually can be "chained", forming asynchronous //pipelines// of messages, as will be illustrated in the next section.
 +
 +As an example of a pipeline of message sends, consider the following code:
 +
 +<code>
 +def booleanFuture := remoteObject<-ask(something);
 +booleanFuture<-ifTrue: {
 +  ...
 +} ifFalse: {
 +  ...
 +}
 +</code>
 +
 +In this example, the message ''ifTrue:ifFalse:'' is sent to a future which will be resolved with a boolean object (the answer to the ''ask'' method). When the ''booleanFuture'' becomes resolved, it will forward the message to its resolved value. The above code shows how you can postpone the execution of code until a future becomes resolved. However, this particular synchronisation technique only works for (futures for) booleans. The following section describes a more general synchronisation technique to await the value of a future for any kind of value.
  
 ==== Working with Resolved Futures ==== ==== Working with Resolved Futures ====
Line 271: Line 286:
 </code> </code>
  
-Finally, it is useful to know that ''when:becomes:'' itself returns a future, who will be resolved with the value of applying the observer closure: +Finally, it is useful to know that ''when:becomes:'' itself returns a future, which will be resolved with the value of applying the observer closure: 
  
 <code> <code>
Line 318: Line 333:
 An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as ''send'' and ''receive'' that can be overridden to customise e.g. message sending on a per-object basis. An actor in AmbientTalk is primarily a //host// for regular objects. It is equipped with a message queue to receive asynchronous messages sent to one of its objects. The mirrors on these objects have corresponding meta-level operations such as ''send'' and ''receive'' that can be overridden to customise e.g. message sending on a per-object basis.
  
-Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, the programmer could override the way messages are sent by any object from within an actor. The mirror on an actor that reifies these operations is bound to the ''actor'' variable, defined at top-level. Evaluating ''actor'' returns the mirror on the current actor. It defines operations such as ''createMessage'' and ''send'' which can be explicitly invoked, or even overridden by the programmer.+Some operations, such as creating and sending asynchronous messages are useful to reify at the //actor level//. With such a reification, the programmer could override the way messages are sent by any object from within an actor. The mirror on an actor that reifies these operations can be acquired by invoking the function ''reflectOnActor()'', defined at top-level. Evaluating ''reflectOnActor'' returns the mirror on the current actor. It defines operations such as ''createMessage'' and ''send'' which can be explicitly invoked, or even overridden by the programmer.
  
-Overriding the actor's metaobject protocol can be done by //installing// a new protocol object. This is done by invoking the ''install:'' method on ''actor''. The following code installs a new MOP that logs any messages sent by any object in the current actor:+Overriding the actor's metaobject protocol can be done by //installing// a new protocol object. This is done by invoking the ''becomeMirroredBy:'' method on the actor's mirror. The following code installs a new MOP that logs any messages sent by any object in the current actor:
  
 <code> <code>
-def oldmirror := actor.install: (extend: actor with: {+def actor := reflectOnActor(); 
 +def oldmirror := actor.becomeMirroredBy: (extend: actor with: {
   def send(msg) {   def send(msg) {
     log(msg);     log(msg);
Line 331: Line 347:
 </code> </code>
  
-Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent's behaviour simply by means of a super-send. Note also that the ''install:'' primitive returns the previously installed mirror. This is useful for when an actor mirror should only temporarily be installed. The old mirror can later be re-installed.+Notice that, in this example, the new metaobject protocol is an extension of the old protocol. This enables it to invoke its parent's behaviour simply by means of a super-send. Note also that the ''becomeMirroredBy:'' primitive returns the previously installed mirror. This is useful for when an actor mirror should only temporarily be installed. The old mirror can later be re-installed.
  
 <note> <note>
at/tutorial/actors.txt · Last modified: 2020/02/05 21:26 by elisag