here - Stefan-Marr.de

5. An Ownership-based MOP for Expressing Concurrency Abstractions
the operations on the target object and thus, allow developers to adapt the
language’s behavior as necessary. It is different from 3-KRS in that a target
object can have multiple metaobjects associated with it. Furthermore, the semantics
defined by the proxy are only applied if a client interacts with the
target object through the proxy, which can be a significant drawback. On the
other hand, this design gives a large degree of flexibility, since every target
object can be adapted by arbitrarily many customizations as long as the client
uses the proxy instead of the target object.
Group-based Tanter further discusses the variation of group-based MOPs.
Instead of having a distinct metaobject for every base-level object, for instance
Mitchell et al. [1997] and Vallejos [2011] argue that it can be an advantage to
enable a metaobject to describe the semantics of a set of objects. Mitchell et al.
[1997] use meta-groups to control scheduling decisions for base and metaobjects.
Describing these semantics based on groups of objects instead of separate
objects avoids the need for synchronization between multiple metaobjects,
when scheduling decisions have to be made.
Message-based The message-reification-based models Tanter discusses provide
a meta interface to specify the semantics of message sends, for instance
by taking sender and receiver into account. For example, Ancona et al. [1998]
propose a model they call channel reification, which is based on messagereification.
However, since the model is based purely on communication and
does not reify, e. g., object field access, it is too restrictive for our purposes.
Conclusions Overall, metaobject protocols seem to be a good fit with the
requirements identified for a unifying substrate in multi-language VMs (cf.
Sec. 3.4). However, some of the approaches do not provide sufficient support
to satisfy all of the requirements.
The metaclass-based model is too restrictive, because it is not orthogonal to
application and library code. Sec. 2.5 describes the vision of using the appropriate
concurrent programming concepts for different challenges in a Mail
application. It argues that event-loop-based actors are a good fit for implementing
the user interface, while an STM is a good fit to interact with the
database and to ensure data consistency. Considering that such an application
would rely on a number of third-party libraries for email protocols and
user interface components, these libraries need to be usable in the context
of event-loop actors as well as in the context of the STM. When using a
112