Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aspectj-users] type casting

Thanks for pointing this paper out.

The paper suggests that casting is important as a way to "create"
new references of a given type.  Picking out such points is
useful for proxying (or mocking).  Then the mock/proxy object
takes full responsibility for changed behavior.  This is a nice
pattern because it modularizes a set of behavior changes in
one place and gives it a natural lifecycle.[1]  I think that's
a more compelling use case than the ones I proposed.

It also means we should be explicit about the return type:

  - cast(Type)
  [..]
  The join point returns a value of the type being cast-to.

Wes

P.S. - Here's the advice:

  interface Business { ... }
  class BusinessProxy implements Business {
      BusinessProxy(Business b) {...}
  }

  aspect WrapBusiness {
    Business around(Object input) : cast(Business) && target(input)
            && !target(BusinessProxy) && !within(WrapBusiness) {
        if (input instanceof Business) {
            return new BusinesProxy((Business) input);
        } else if (null == input) {
            throw new NullPointerException();
        } else {
            throw ClassCastException(input.getClass().getName());
        }
    }
  }

Programmers using this to proxy will be careful to exclude the
advice itself if they cast their results, or risk the advice
advising itself.

[1] It's not nice where reference identity is required, or
where delegation to the original reference is difficult or
infeasible, but those are known problems with proxying, not
with using AspectJ to proxy.

kviggers@xxxxxxxx wrote:

A once saw a proposal for a cast join point. Here is the link:

http://quercusseg.unex.es/jclemente/phdoos03/papers/paper1.pdf



-----Original Message-----
From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
admin@xxxxxxxxxxx] On Behalf Of Wes Isberg
Sent: November 23, 2003 10:17 AM
To: aspectj-users@xxxxxxxxxxx
Subject: Re: [aspectj-users] type casting

Frank Xia wrote:

> As I understand, current AspectJ 1.1 doesn't have a join point to catch
> typing casting but does anyone have any clever workaround? If not,
anyone
> know when AspectJ would extent to have this kind of join point?

Interesting!

As far as I know, no one has suggested a cast join point.

There is no workaround that I know of, though you can advise any
join point throwing ClassCastException:

   after() throwing (ClassCastException e) : ... {}


As for a cast join point, it seems feasible to implement the
join point for explicit cast operators using either source
or bytecode (checkcast takes the type being cast-to).

What would you use it for?

Assuming the docs:

  - cast(Type)
  This picks out join points where a reference is being cast to Type.
  The reference being cast is available as target at this join point.
  {optionally: the type being cast-to is available as the single
   argument at this join point, as a variable of type Class.}

Here's one use case, to log:

  after(Object ref, Class c) throwing (ClassCastException e) :
          cast(Runnable) && target(ref) && args(c) {
      log(e + " after casting " + ref + " to " + c);
  }

Here's another use case, to throw your own exceptions.  You could
even do so when there wouldn't be a ClassCastException.

  before(MyRunnable runner) : cast(Runnable) && args(runner) {
      throw new CastError(runner, Runnable.class);
  }

Here's another definition and use case:

  - cast(TypePattern)
  {ditto} any type matching TypePattern

  declare error : cast(*) && within(com.company.internal.critical..*) :
     "casts not permitted in critical code";

Other use cases?

Jim once stated a standard for new language features as

  needs to have both a convincing example of where it is a real and
  important problem as well as a fairly concrete proposed solution.

I believe that this has a concrete solution [but I'm not the
compiler writer], so the main question is whether the added
language complexity is worth the benefit of the use cases.

Thanks -
Wes

P.S. - I haven't thought about it carefully enough to know that there
are no implicit casts that resolve to a cast operator.  It will confuse
developers to find join points not reflected in source. Conversely,
some cast operators are superfluous; I'm not sure the compiler isn't
permitted to optimize them away, confusing the developer who expected
a join point there.  If the join point doesn't follow expectations,
then we have to take into account that users might be confused when
the join point is surfaced using AspectJ when considering whether to
add it to the language.  I.e., I think a new join point should be
part of the existing programmer's model or a clear extension to it.


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



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




Back to the top