Re: [abc-dev] Why are ITD methods woven as they are

From: Pavel Avgustinov <pavel.avgustinov_at_magd.ox.ac.uk>
Date: Wed, 7 May 2008 11:02:18 +0100

On Wednesday 07 May 2008 10:24:15 Wouter De Borger wrote:
> Our implementation strategy leaves the code for intertype methods as static
>
> > methods in the originating aspects. This avoids the use of accessor
> > methods for accessing members of the aspect scope (and that is the
> > vantage point for visibility tests). Also, the method is then considered
> > as part of the aspect for name matching, which is the desired behaviour.
>
> I don't understand the second argument. Can anyone explain this?

From an intertype method, you can see members of the enclosing aspect as if
the method was actually an aspect method. Also, you cannot see private
methods of the class the ITD method is declared on (unless the aspect is
privileged -- well, at least that's my understanding, I may be wrong).
Finally, if you make reference to nested classes, these will be resolved from
the scope of the aspect, not the host class of the ITD.

As the technical report says, the reason this is the implementation strategy
is largely simplicity; it requires fewer modifications to name resolution
code.

> BTW: This choice als leads to bug
> 88<http://abc.comlab.ox.ac.uk/cgi-bin/bugzilla/show_bug.cgi?id=88>for
> static methods

Correct. The static methods introduced on the aspect should have a mangled
host type name on them.

Incidentally, the bug above doesn't apply to abc's new JastAdd-based frontend,
which does introduce ITDs directly onto the host class rather than on the
aspect instance. Turns out that modifying name lookup is a lot easier in the
context of JastAdd than it was with the old frontend. :-)

- P
Received on Wed May 07 2008 - 11:02:32 BST

This archive was generated by hypermail 2.2.0 : Wed May 14 2008 - 22:40:10 BST