From: Clifford Heath <no@...>
Date: 2008-02-25T08:20:04+09:00
Subject: Re: Monkeypatching is Destroying Ruby

Phlip wrote:
>> http://avdi.org/devblog/?p=18
> I don't know what "Aspect Oriented Programming"....

> I want this:
(clip)
> I want .inspect, or whatever, outside my module, to behave normally. But if 
> you inspect a string while my module is above you on the call stack, I get 
> my hotwired version of .inspect.
> Does anyone have a Ruby Hack which does that yet? How hard would it be?

It can't be done in Ruby. I spent quite a lot of time analysing how to
construct such a language, as I've used this kind of design principle
for more than a decade to design aspect-oriented object models.

The problem is that for every call, you need to pass in a hidden parameter
which contains a descriptor for every namespace visible from the caller's
perspective, and you need to use that list of namespaces to disambiguate
the method call itself. Access to other parameters of the method from
inside the callee is also a problem, as they may be of classes that "don't
exist" from the POV of the callee.

Basically, such a language is possible, but I don't believe the implementation
can be made efficient.

A more restricted version of this behaviour can be done by treating every
aspect-limited extension (which I call a facet) of an object, as a special
kind of subclass. Such a subclass must not be allowed private access; it
can only use the public interface of its superclass. The superclass instance
is initially instantiated as just the superclass, but the facet methods are
"realized" as they're used, revealing the aspect behaviour of the object.
Again, this can't be faked very well in Ruby, and the various Traits modules
are a better solution.

However, I do believe that from a modeling POV, the approach is very valuable.
My ActiveFacts project explores the only real way to do this effectively,
which is in terms of elementary fact types. That means that all roles of
each object type are specified in one or more vocabularies (aspects), and
since the fact types are *elementary*, they're totally composable.

The same approach isn't easy to extend to modeling behaviour, for the
reasons I mentioned. You say tomato, I say tomatoe, but in Ruby, the
composition of the two things can only have one name, or you get collisions.
Unless you want to modify a Ruby interpreter to allow you to monkey-patch
Method#call, but then you're implementing your own VM :-).

Clifford Heath.