User Tools

Site Tools


at:tutorial:reflection

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:tutorial:reflection [2008/11/06 15:36]
elisag
at:tutorial:reflection [2009/11/30 16:54]
dharnie *prog->soft
Line 138: Line 138:
 ===== The Metaobject Protocol ===== ===== The Metaobject Protocol =====
  
-The Meta-Object Protocol of AmbientTalk can be divided into a series of independent protocols. Whereas the full semantics and signature of the meta-methods can be found in the [[http://prog.vub.ac.be/amop/at2langref/edu/vub/at/objects/MirrorRoot.html|language reference]], this section provides an overview of the various protocols.+The Meta-Object Protocol of AmbientTalk can be divided into a series of independent protocols. Whereas the full semantics and signature of the meta-methods can be found in the [[http://soft.vub.ac.be/amop/at2langref/edu/vub/at/objects/MirrorRoot.html|language reference]], this section provides an overview of the various protocols.
  
-The **Message Passing Protocol** consists of methods to deal with both synchronous and asynchronous message sending. It provides necessary hooks to intercept both the reception of asynchronous messages and the invocation of synchronous messages. Moreover, it provides a hook to intercept asynchronous messages being sent by the object, allowing the object to add additional metadata to the message. The ''invoke'' meta-method illustrated above is an example of a method belonging to this protocol.+The **Message Invocation Protocol** consists of methods to deal with both synchronous and asynchronous method invocation. It provides necessary hooks to intercept both the reception of asynchronous messages and the invocation of synchronous messages. Moreover, it provides a hook to intercept asynchronous messages being sent by the object, allowing the object to add additional metadata to the message. The ''invoke'' meta-method illustrated above is an example of a method belonging to this protocol. The picture below gives an overview of that protocol.
  
-The **Object Passing Protocol** consists of two methods ''pass'' and ''resolve'', which allow an object to prescribe how it should be passed to other objects and how the object should subsequently be resolved upon arrival. The default semantics allow objects to be passed by copy if they are tagged with the ''Isolate'' type tag. Otherwise, objects are passed by handing out a far object reference.+{{:at:tutorial:msgReceptionProtocol.jpg?500|:at:tutorial:msgReceptionProtocol.jpg}} 
 + 
 +The **Object Marshalling Protocol** consists of two methods ''pass'' and ''resolve'', which allow an object to prescribe how it should be passed to other objects and how the object should subsequently be resolved upon arrival. The default semantics allow objects to be passed by copy if they are tagged with the ''Isolate'' type tag. Otherwise, objects are passed by handing out a far object reference.
  
 The **Slot Access and Modification Protocol** consists of operations which allow trapping both dynamic access and modification to slots. For instance, ''o.x'' can be intercepted using the ''invokeField'' meta-method, while ''o.x := 5'' is trapped using ''invoke'' where the selector will equal ''x:=''. The **Slot Access and Modification Protocol** consists of operations which allow trapping both dynamic access and modification to slots. For instance, ''o.x'' can be intercepted using the ''invokeField'' meta-method, while ''o.x := 5'' is trapped using ''invoke'' where the selector will equal ''x:=''.
  
-The **Structural Access Protocol** consists of operations used list all available slots, get access to a first-class slot representation and to add new slots to an existing object. The ''listSlots'' meta-method used in previous example is a member of this protocol.+The **Structural Access Protocol** reifies the structure of an AmbientTalk objects as a collection of slot objects. It consists of operations used list all available slots, get access to a first-class slot representation and to add new slots to an existing object. The ''listSlots'' meta-method used in previous example is a member of this protocol. 
  
-The **Instantiation Protocol** consists of the ''clone'' and ''newInstance'' methods, which are implictly called when using base-level code of the form ''clone: object'' and ''object.new(@args)'' respectively. In the default implementation, ''newInstance'' calls ''clone()'' to create a clone of the current object, and subsequently invokes the base-level ''init'' method with the supplied arguments on the cloned object.+The **Object Instantiation Protocol** consists of the ''clone'' and ''newInstance'' methods, which are implictly called when using base-level code of the form ''clone: object'' and ''object.new(@args)'' respectively. In the default implementation, ''newInstance'' calls ''clone()'' to create a clone of the current object, and subsequently invokes the base-level ''init'' method with the supplied arguments on the cloned object.
  
 The **Relational Testing Protocol** consists of the methods ''isCloneOf'' and ''isRelatedTo'' which allow testing whether 2 objects are related through cloning or a combination of cloning and object extension. Note that these operators are not able to discern that objects were generated by the same constructor function or (by extension) the execution of identical code in different actors.  The **Relational Testing Protocol** consists of the methods ''isCloneOf'' and ''isRelatedTo'' which allow testing whether 2 objects are related through cloning or a combination of cloning and object extension. Note that these operators are not able to discern that objects were generated by the same constructor function or (by extension) the execution of identical code in different actors. 
  
-The **Type Testing Protocol** consists of the methods ''isTaggedAs'' and ''getTypeTags'', the former of which tests whether an object is transitively tagged with a particular type (i.e. this operation considers type tags of parent objects). ''getTypeTags'' on the other hand returns only the type tags which were explicitly attributed to this object (i.e. it does not return type tags attributed to the parent objects).+The **Type Tag Protocol** consists of the methods ''isTaggedAs'' and ''listTypeTags'', the former of which tests whether an object is transitively tagged with a particular type (i.e. this operation considers type tags of parent objects). ''listTypeTags'' on the other hand returns only the type tags which were explicitly attributed to this object (i.e. it does not return type tags attributed to the parent objects).
  
 The **Evaluation Protocol** ensures that any AmbientTalk object can be part of a parse tree, and therefore every object provides meaningful implementations of the ''eval'' and ''quote'' meta-operations. The ''eval'' operation is called when evaluating a parsetree and typically returns the evaluated object itself, except for explicit parse-tree elements such as definition and method invocations.  The **Evaluation Protocol** ensures that any AmbientTalk object can be part of a parse tree, and therefore every object provides meaningful implementations of the ''eval'' and ''quote'' meta-operations. The ''eval'' operation is called when evaluating a parsetree and typically returns the evaluated object itself, except for explicit parse-tree elements such as definition and method invocations. 
at/tutorial/reflection.txt · Last modified: 2010/11/16 16:32 by tvcutsem