On 13.06.2008, at 05:18, Kurt Stephens wrote:
James McCartney wrote:
I hope this doesn't come across as adversarial since I am sincerely
interested in this, but I am troubled by the sideways composition
paper.
It seems as if it is an existence proof that the id object model's
intention of having "messaging semantics that are described entirely
in terms of those same objects and messages" is not attained.
Implementing sideways composition required changing send and bind
which are not redefinable within the system. Only lookup can be
redefined in the vtable. The sideways composition as implemented is
still not able to handle multiple delegates. There isn't a way for an
object A that wants to delegate first to B and then to C (if B does
not already itself delegate to C). The single delegation mechanism is
hard coded in bind which is not redefinable from within.
There is nothing that prevents bind() from being decomposed with
messages to other object: bind() is decomposed into lookup().
For example: libid_bindv() does infact use send() to do the lookup()
operation; it only uses the single delegation lookup() behavior if a
recursion is detected. There maybe some additional MOP-like protocols
that can remove the need for the recursion detection.
As for recursion detection... I think that the solution might be to make
"meta-level execution" distinguishable from "non-meta".
(or, another way to look at it: make the system "look different"
depending
on if we are meta or not, nicely fitting into the "multiple
viewpoints" way of
looking at things).
Here is a paper where I describe a system that uses this idea to avoid
meta-object call recursion:
“The Meta in Meta-object Architectures,”
Proceedings of TOOLS EUROPE 2008, LNBIP, vol. 11, 2008, pp. 218-237.
http://www.iam.unibe.ch/~scg/cgi-bin/scgbib.cgi/abstract=yes?Denk08b
Just a very first step... but I think an interesting direction to
explore further.
Marcus
--
Marcus Denker -- [EMAIL PROTECTED]
http://www.iam.unibe.ch/~denker
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
