[aspectc-user] Aspect templating

[Manuel Menezes de Sequeira]

Hi Olav,

Olaf Spinczyk wrote:

> [...]
> I very much sympathize with the idea of aspect templates. However, I 
> would object against different instantiation schemes for aspect 
> templates and ordinary aspects. This would be confusing for programmers.

Maybe we should clarify what we mean by "instantiation".  Within the C++ 
"culture", a class template is instantiaded into a class, which is then 
instantiated into instances or objects.  Class template instantiations 
are usually implicit, but always (as far as I remember) as a result of 
some code which makes explicit use of the class template, providing it 
with arguments.  Class template instantiation, however, can be made 
explicit.  Class instantiation is (usually?) explicit, in the sense that 
one has to explicitly define variables or call operator new.  Aspects 
are different, since they are instantiated by the code generated by the 
weaver, which is not under the programmers control.  Hence, aspect 
instantiation is implicit.  The question here is how aspect templates 
should behave.  They cannot usually be implicitly instantiated into 
aspects through explicit parametrization, for the simple reason that the 
programmers' code generally does not make explicit reference to 
aspects.  After all, we want obliviousness to apply.  It might be 
possible, for instance, to check at each join point whether some 
parametrization of an aspect template would have a matching pointcut, 
but I think this would be overly complex.  Hence, I think aspect 
templates should be explicitly instantiated.  That is:

Class: explicit instantiation (into object)
Class template: mostly implicit instantiation, explicit instantiation 
possible (into a class)
Aspect: implicit instantiation (generally into singleton and weaved advice)
Aspect template: implicit instantiation to hard/complex (if at all 
possible), explicit instantiation desirable (?) (into an aspect)

Notice that an aspect resulting from the explicit instantiation of an 
aspect template would be implicitly instantiated as any other aspect.

> We could ...
>
> (A) allow aspect template parameters only for abstract aspects, where 
> a derived
>    concrete aspect would pass the parameter, and for concrete aspects 
> with a
>    user-defined instantiation scheme (by implementing aspectof).
>
> (B) no longer support the implicit instantiation (a feature that we 
> simply
>    copied from AspectJ without thinking about it very long) anymore. The
>    advantage would be that aspect inheritance would no longer have to be
>    restricted to abstract aspects, which in my opinion is an 
> artificial restriction
>    that often circumvents reuse of aspect code.
>
> Here is an example for (B):
>
> --- Foo.h ---
> aspect Foo { ... }; // a concrete aspect
> ---
>
> --- Bar.h ---
> #include "Foo.h"
> template <typename T> aspect Bar : public Foo { ... }; // a template
> ---
>
> --- MyFooBar.ah ---
> #include "Bar.h"
> #include "My.h"
> extern Bar<My> myFooBar;  // a global aspect instance
> extern Foo myFoo; // another aspect
> ---
>
> --- MyFooBar.cc ---
> #include "MyFooBar.ah"
> Bar<My> myFooBar;  // here the storage for the aspect instances is 
> statically
> Foo myFoo;  // allocated
> ---
>
> What is your opinion about explicit instantiation?

I think it would have the following problems:
a) It would make AspectC++ diverge from what programmers are getting 
used to expect from AspectJ-like languages.  This would make adoption of 
AspectC++ harder.
b) What would happen if two libraries would explicitly instantiate the 
same aspect?  Would there be two instances?  To which would the advice 
code refer (think of aspects with member variables)?  Would the advice 
be weaved twice?

> What do you think about the problem of redundant concepts? A pointcut 
> is more powerful than a template parameter, because you can use it to 
> parameterize an aspect with sets of classes/functions or other join 
> points. Instead of supporting aspect templates we could alternatively 
> add a language mechanism that allows one to define a type accordings 
> to the value of a poincut, e.g.
>
> aspect X {
>  pointcut virtual target_class() = 0;
>  typedef typeof(target_class()) T;
>  T attribute;
>  T func(T);
>  advice target_class() : int intro;
> };
>
> Any opinions on these issues?

What if the pointcut ends up matching several classes?  I don't think 
this would work unless aspects were instantiated per target.  Besides, 
the two concepts do not really match.  They overlap in some cases, but 
there are many cases in which they do not.  In the cases where the is an 
overlap, the programmer may choose the solution which seems more natural.

Besides aspect templates, I think something like pointcut templates 
would also be very usefull, and easy to instantiate implicitly.  One of 
the main limitations of the syntax used by AspectJ (and I think 
AspectC++ too) to specify pointcuts (using quantification for joinpoint 
selection) is that one is forced to use wild cards.  Providing support 
for dummy variables would be very useful.  It would require pointcuts to 
have two sets of parameters.  The first, which already exists in 
AspectC++, would be the parameters for the captured context.  The second 
would be dummy variables to be used in matching expressions.  Here's the 
idea in AspectJ (example from a message in aspectj-users):

    pointcut setsWithinAnnotatedMethod(/*context variables here*/)
    [TypePattern class_name: * /*dummy variables here*/] :
    withincode(@Annotation* class_name.*(..)) && set(* class_name.*);

This would match sets to atributes of a class performed within methods 
of the same class.  Perhaps there is a better solution to this problem 
with the existing AspectC++, but you get the idea.

Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20050505/2ca336b9/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3198 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.aspectc.org/pipermail/aspectc-user/attachments/20050505/2ca336b9/attachment.bin>