here - Stefan-Marr.de

5. An Ownership-based MOP for Expressing Concurrency Abstractions
while Albedo comes close, it would require changes to fulfill the requirements
identified in Sec. 3.4.
The proxy-based metaobject protocol for ECMAScript [Van Cutsem and
Miller, 2010] comes close to satisfying these requirements as well. It reifies all
relevant intercession operations, however, since it is proxy-based, it does not
provide the same guarantees the ownership-based approach provides. The
use of proxies requires careful handling of references to avoid leaking the actual
objects, which would then not be subject to an enforcement of language
guarantees. On the other hand, the proxy approach provides a natural way
to combine semantics of multiple metaobjects, since proxies can be chained.
While the proxy-based approach has this advantage, the ownership-based approach
simplifies the intended standard use cases. On the one hand, it does
require only one metaobject, i. e., the domain object, to define the concurrency
semantics for a group of objects, and on the other hand, it does not require distinguishing
between proxies and target objects, which could be leaked, since
the ownership property establishes the meta relation.
Grouping and Ownership-based Approaches The notion of meta-groups
proposed by Mitchell et al. [1997] is close to the notion of ownership used
by the OMOP. They use their meta-groups MOP to define real-time properties
by providing the ability to reflect over timing-related information and
to customize scheduling-related behavior. Their intention is to describe the
semantics for groups of objects conveniently and to avoid the need for synchronization
between multiple metaobjects, when scheduling decisions have
to be made.
Similar notions have been used in ACT/R [Watanabe and Yonezawa, 1991]
and ABCL/R2 [Masuhara et al., 1992]. The focus is on group communication
and maintaining constraints among groups of objects. To this end, the
MOP reifies message sends as tasks, the creation of new actors, the state
change of existing actors via become, and the execution of a method body.
In contrast to the OMOP, ACT/R supports infinite meta-regression in terms
of an infinite reflective tower, while the OMOP uses the notion of enforced
and unenforced execution to be able to terminate meta-regression explicitly.
Another consequence of this design is the absence of ACT/R’s inter-level
communication, which requires special addressing modes when sending messages
between the base and meta level. Instead, the unenforced flag and the
#evaluateEnforce: method make the switch between the execution levels,
i. e., enforcement mode explicit.
132