Skip to main content

[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




Ron and Antti,

Nice idiom. A more succinct form:

public interface Interface {

      public void method ();
}

public aspect AnotherAspect {

      private interface AnotherInterface {}

      declare parents : Interface extends AnotherInterface;

      private int AnotherInterface.intField = 999999;

      before (AnotherInterface i) : execution(void method()) && this(i) {
            System.err.println("intField=" + i.intField);
      }

}

The issue with accessor methods for ITD fields has nothing to do with
visibility or privileged access. In the advice above the variable is of the
interface type _not_ the concrete implementation which actually "hosts" the
field. The code is build independently of any implementers so the accessor
methods are required.

Another exception to transparency is Serialization which can affected by
the addition of fields and methods at the implementation level. This is
covered in the current documentation. However what I suspect is missing is
a general discussion of mixed Java/AspectJ implementations and their
evolution.

Matthew Webster
AOSD Project
Java Technology Centre, MP146
IBM Hursley Park, Winchester,  SO21 2JN, England
Telephone: +44 196 2816139 (external) 246139 (internal)
Email: Matthew Webster/UK/IBM @ IBMGB, matthew_webster@xxxxxxxxxx
http://w3.hursley.ibm.com/~websterm/

"Ron Bodkin" <rbodkin@xxxxxxxxxxxxxx>@eclipse.org on 06/04/2005 12:57:34

Please respond to aspectj-users@xxxxxxxxxxx

Sent by:    aspectj-users-bounces@xxxxxxxxxxx


To:    <aspectj-users@xxxxxxxxxxx>
cc:
Subject:    RE: [aspectj-users] Default implementations     inaninterface
       causingcreation of extra methods in an interface


Antti,

Could you use this idiom?

aspect Foo {
    public interface InternalImplIface extends RealIface {}

    // Make your ITD's on InternalImplIface

    declare parents: (RealIface+ && !RealIface) implements
InternalImplIface;
}

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
members.

-----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?



     -Antti-




_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users

_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/aspectj-users




Back to the top