<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=windows-1252"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<meta content="text/html;charset=windows-1252" http-equiv="Content-Type">
<title></title>
Hi Olav,<br>
<br>
Olaf Spinczyk wrote:<br>
<blockquote cite="mid42789D74.1030607@informatik.uni-erlangen.de"
type="cite">[...]<br>
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. <br>
</blockquote>
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:<br>
<br>
Class: explicit instantiation (into object)<br>
Class template: mostly implicit instantiation, explicit instantiation
possible (into a class)<br>
Aspect: implicit instantiation (generally into singleton and weaved
advice)<br>
Aspect template: implicit instantiation to hard/complex (if at all
possible), explicit instantiation desirable (?) (into an aspect)<br>
<br>
Notice that an aspect resulting from the explicit instantiation of an
aspect template would be implicitly instantiated as any other aspect.<br>
<blockquote cite="mid42789D74.1030607@informatik.uni-erlangen.de"
type="cite">We could ... <br>
<br>
(A) allow aspect template parameters only for abstract aspects, where a
derived <br>
concrete aspect would pass the parameter, and for concrete aspects
with a <br>
user-defined instantiation scheme (by implementing aspectof). <br>
<br>
(B) no longer support the implicit instantiation (a feature that we
simply <br>
copied from AspectJ without thinking about it very long) anymore.
The <br>
advantage would be that aspect inheritance would no longer have to
be <br>
restricted to abstract aspects, which in my opinion is an artificial
restriction <br>
that often circumvents reuse of aspect code. <br>
<br>
Here is an example for (B): <br>
<br>
--- Foo.h --- <br>
aspect Foo { ... }; // a concrete aspect <br>
--- <br>
<br>
--- Bar.h --- <br>
#include "Foo.h" <br>
template <typename T> aspect Bar : public Foo { ... }; // a
template <br>
--- <br>
<br>
--- MyFooBar.ah --- <br>
#include "Bar.h" <br>
#include "My.h" <br>
extern Bar<My> myFooBar; // a global aspect instance <br>
extern Foo myFoo; // another aspect <br>
--- <br>
<br>
--- MyFooBar.cc --- <br>
#include "MyFooBar.ah" <br>
Bar<My> myFooBar; // here the storage for the aspect instances
is statically <br>
Foo myFoo; // allocated <br>
--- <br>
<br>
What is your opinion about explicit instantiation? <br>
</blockquote>
I think it would have the following problems:<br>
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.<br>
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?<br>
<blockquote cite="mid42789D74.1030607@informatik.uni-erlangen.de"
type="cite">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. <br>
<br>
aspect X { <br>
pointcut virtual target_class() = 0; <br>
typedef typeof(target_class()) T; <br>
T attribute; <br>
T func(T); <br>
advice target_class() : int intro; <br>
}; <br>
<br>
Any opinions on these issues? <br>
</blockquote>
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.<br>
<br>
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):<br>
<blockquote>pointcut setsWithinAnnotatedMethod(/*context variables
here*/) [TypePattern class_name: * /*dummy variables here*/] :
withincode(@Annotation* class_name.*(..)) && set(*
class_name.*);<br>
</blockquote>
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.<br>
<br>
Manuel<br>
</body>
</html>