Kinds of Delegation
In my first post, I want to discuss how interestingly delegation can be thought in terms of object structure. My major reference here is the paper Delegation as a Sharing Relation: Characterization and Interpretation (made by Daniel Bardou). But, first and foremost, let’s discuss what is intrinsic to all object structures.
We can sketch an object in terms of a table: let’s call the first column as the selector and the second one as the value. Also, we’ll call every row, from now on, as simply property, which is a pair/entry of an unique selector pointing to any value.
Selectors in any table (i.e, object) can’t change, otherwise the uniqueness of object’s selection (accessing the
state or sending some message) is broken. In SQL terms, this column will be the primary key. ‘Cause state mutations
occur frequently, our value column is also writable. Pay attention that, despite selectors being read-only, they can be
removed if the whole entry (that is, the property) is also removed. This property erasing mechanism may be performed
while setting a special value, such as
undefined or whatever, but in our discussion it will be
erase (I’m reserving
nil to trigger lookup in parent objects).
Bardou shows different kinds of sharing among inheritance and delegation, and also compares them in his paper. For me, I will take two kinds of delegation sharing, called as property sharing and value sharing. Firstly, I will show how value sharing can be represented below:
As you can see, the value of the child’s
move selector is linked to the value of the parent’s
value. Thus any change performed on the parent’s
move-related value will be reflected and synchronized with the
move-related value. If the child object performs non-nil changes in its own
move-related value field, the
link between this child and its parent on that selector is gone. By now, this topic suffices. Let’s head toward
property sharing delegation.
From the example above, we can easily deduce that the child’s selection itself will be delegated to its parent rather than delegating the lookup of some non-nil value. It has interesting implications, the main one is that not only the state access can be delegated, but also the state mutation (because this is performed after finding a proper property). This, in the literature, is known as split objects representation. We also can easily implement subjective/contextual programming with that. Nevertheless, without the proper care, it can lead to inconsistent softwares, mostly ‘cause it gives the power to the child object break encapsulation of its parent, and when there is a bunch of child objects, things can be out of control, worst even in non-concurrent environments.
So, which is the best sharing delegation mechanism? The answer is both. While the former (i.e, value sharing) protects the object’s identity, it also encapsulates too much to the point where an object may end with too much responsibilities/concerns. For the latter, it is very useful to provide well-factored code, proper separation of concerns, maintainable and modular code, etc, but state mutations can break your system reasoning through entangled web of dependencies. For the rule of thumb, use property sharing when the state changes don’t occur often, and value sharing when your object is not taking too much methods in its behavior.
To implement a proof of concept, I have chosen the Lua language. The code is shown below (don’t worry, I’ll explain step by step every piece of code):
In his paper, Bardou cites an interesting issue:
Property sharing raises also the problem of object identity. If child objects have to be considered as extensions of their parents, one can not put any frontier between objects: every object can create an extension of another one in order to gain full access to its properties. This problem is well discussed in .
To address that, I’m using the
protected property to put some frontier between objects: an object only can
be split into another representation if this property is set to
false. By default, this property is set to
true and is inherited by all descendants of
prototype. Nevertheless, objects themselves may overwrite this
in their own properties. ‘Cause this property can be modified during runtime, triggered delegation of mutation
on parent’s properties may fail. I have put this constraint to give us a soundness feeling of the system.
There are 3 types of metatables, one for every kind of operation performed among objects, which are cloning,
split extension and read-only aliasing (this latter for the sake of good practices). Cloning here stands for
value sharing while extension stands for the property sharing. The lookup algorithm goes into the
which is not late-bound to disable unwanted recursion. The
parent slot is also writable, which gives us Self’s
behavioral modes for free (although our design decision is almost limited as like single-inheritance).
erase property is a kind of final implementation in the same way of Java’s
final keyword: it can’t be
overridden and is also inherited by all children objects. The value of the
erase property halts the lookup if
it is not being run with the
erase selector (we still need to access this magic value through
all). When the lookup stops by halting or by failure, it “re-dispatchs” the selection to the
missing error handling
method, which is expected to deal with non-existent properties.
Finally, we export an immutable alias of the
prototype to prevent external modifications into this object. If you
are paying attention enough, you may have noticed that it disallows us to call
extend directly into
(‘cause we can’t modify the already set
protected property), this is due the fact that the prototype plays the role of an
abstract object to provide a small set of behaviors while also being a factory of objects through the
operation. Observe also that, despite being immutable, the external reference of prototype can, without problems,
create mutable instances. It’s also valid for every kind of immutable
view of an object…
A silly example of how using the implementation module follows:
Oh God, I am tired… stay tuned on for further posts here. Thanks.
Updated on May 5, 2017