RE: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertyp

[Eric Bodden <eric@xxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Thanks for the discussion.
Commenting on the "weaknesses" you mentioned:

Nicholas Lesiecki wrote:
> weakness 1) You could mismatch your association pointcut so that it
> never selected objects of the appropriate type (this is probably 
> livable)
Good point. My proposal here would be to get rid of the type
signature list in the perobject clause completely and infer the
declared types in any piece of advice that uses "associate" during
the compilation process. Declared types suffice since they must
always be a supertype of the runtime type. Also those types should be
quite straightforward to infer through one simple pass.

> weakness 2) New types might match the association pointcut but not
> match the per clause type(pattern?)
See 1), which would eliminate this, too.

> weakness 3) the association
> advice would appear in an aspect whose other advice does not apply
> unless the aspect has already been associated, meaning that the
> association advice would need to be demarcated as "special" somehow
>   
One could (and I think Sakurai et al. indeed did, if I understood
correctly) restrict the use of associate(..) to at least one
*mandatory* in each constructor of the perobject aspect. This would
make sure, each aspect instance in properly associated. This would
make all pieces of advice in this aspect apply only, once the actual
aspect instance exists. Problem here: You loose additional,
static-like (singleton) pieces of advice for this instance. But those
should not be per-object and thus go into a distinct aspect anyway...

>  /**@ return aspectOf(input) if non-null, or new aspect */
>  public static A A.enableFor(Object input);

>  /**@ return the aspect dissassociated from the input */
>  public static A A.disableFor(Object input);

I like this proposal. However, this should be something like the
following for association aspects:

  /**@ return aspectOf(input) if non-null, or new aspect */
  public static A A.enableFor(Object.. input); //hope this is correct
syntax

  /**@ return the aspect dissassociated from the input */
  public static A A.disableFor(Object.. input);

So that you can enable/disable for a certain (ordered) list of
objects, which might be associated.
So you might want to enable/isable forced equality relation (see
paper) for two Bit instances by just saying:

Bit b1,b2;
Equality.enableFor(b1,b2);
Equality.disableFor(b1,b2);

To me this looks pretty comprehensible.

W.r.t. GC I think that indeed an associated aspect should be
automatically disposed of, if no object is associated any more or all
associated objects are GCed, given you use weak hashmaps or weak
references for implementation.

Eric

- -- 
Eric Bodden
Chair I2 for Programming Languages and Program Analysis
RWTH Aachen University

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQfuB2swiFCm7RlWCEQLG+QCfWhh2YA6apYxBPE+63tw9dtR0VhwAoIPW
YL64DZodSajkv2cSscv3oV5P
=Ogdb
-----END PGP SIGNATURE-----