[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-users] Default implementations inaninterface causingcreation of extra methods in an interface


Could you use this idiom?

aspect Foo {
    public interface InternalImplIface extends RealIface {}

    // Make your ITD's on InternalImplIface

    declare parents: (RealIface+ && !RealIface) implements

Now for any implementers of RealIface that AspectJ controls, you get the
ITD's. But for pure Java clients of RealIface, they don't see additional

-----Original Message-----
From: aspectj-users-bounces@xxxxxxxxxxx
[mailto:aspectj-users-bounces@xxxxxxxxxxx] On Behalf Of Antti Karanta
Sent: Wednesday, April 06, 2005 2:28 AM
To: aspectj-users@xxxxxxxxxxx
Subject: RE: [aspectj-users] Default implementations inaninterface
causingcreation of extra methods in an interface

> Antti,
> I am assuming you have an interface, an aspect that adds 
> default behaviour
> to the interface and some advice to its implementers, and a class that
> implements the interface. 

  Yes, exactly.

> You have non-AspectJ clients that  use both the interface and your
implementation of it.

  Well, not exactly. The clients just have to implement two interfaces
and make a couple of xml config files to make a plugin. A couple of
these plugins are built in, and I use the aspect to provide the above
mentioned things to their implementations.
  The clients know only one helper class in addition to the two
interfaces needed to implement a plugin.

> 2. The use of advice will also be transparent however 
> implementers of the
> interface not woven with the aspect will obviously not be 
> advised. This may
> or may not be a problem.

  Not a problem as I know that the veawing happens at compile time and
have taken this into account.

> 3. The use of inter-type declared fields will not be 
> transparent to clients
> because interfaces in Java cannot define non-public final 
> static fields.

  I am aware of what Java interfaces are capable of. I just could not
understand why the compiler could not insert the field into the
implementing classes. Now I see the reason as it is apparent from the
example you provided - if the fields are declared w/ other visibility
than private, they are referrable from outside the aspect by all who use
the interface type. So, the general case has to be done the way it is
done now.
  However, I'd argue that "private" is the most common visibility used
for fields in Java. With a private field, I do not see a reason why the
compiler could not insert the field into each of the implementing
classes and take this into account when veawing the advice / inserting
the default method implementations, as no-one outside the aspect
declaring the field can reference the field anyway. I know this would
make the compiler a bit more complex as we would have two ways that
fields declared in interfaces are handled (one for private fields, one
for fields w/ other visibility), but it would also make most interfaces
w/ field introductions non-aspectj client friendly.

  Then again, I guess my reasoning above falls apart in the case where
another aspect that is privileged accesses the declared private field...
and as that aspect can be in another project, we can not ascertain at
compile time of the declaring aspect that no such references exist. So,
even private fields have to be considered visible outside the declaring
aspect. = / 

> Artifacts are sometimes generated as a result of the weaving 
> process but
> they are normally transparent. There are exceptions one of 
> which is public interfaces where the client is not an AspectJ program.

  What are the other exceptions? Are these exceptions documented in a
single place in the documentation? 


aspectj-users mailing list