[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Perobject association (was: [aspectj-dev] pertypewithin() vs. pertype() association...)
- From: Eric Bodden <eric@xxxxxxxxx>
- Date: Sat, 29 Jan 2005 13:30:18 +0100
- Delivered-to: firstname.lastname@example.org
- Organization: RWTH Aachen University
- Thread-index: AcUFdNzgVnio7NyATAW7N77Bpy6HDwAhsO+Q
-----BEGIN PGP SIGNED MESSAGE-----
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
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
/**@ 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:
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.
Chair I2 for Programming Languages and Program Analysis
RWTH Aachen University
-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3
-----END PGP SIGNATURE-----