RE: [aspectj-users] Intertype Declaration for only one target ?!? !?!?

[hilsdale@xxxxxxxx]

It's not quite equivalent in 1.0.6:

Here:
  public void VisitedElement+.accept(Visitor v) { v.visit(this); } 

this is statically typed (important for overloading of the visit method) to whatever type the method is generated into.  Here,

  declare parents: Foo+ implements VisitedElement;
  public void VisitedElement.accept(Visitor v) { v.visit(this); }

this is statically typed to the VisitedElement interface.

I personally believe that, while the former has a place in AOSD, it shouldn't have a place (or have had a place) in AspectJ:  We've always told the story that we are _not_ doing generative programming, and it's really hard to tell a consistent story about the former semantics without talking about generation.

-erik

-----Original Message-----
From: Lesiecki Nicholas [mailto:ndlesiecki@xxxxxxxxx] 
Sent: Friday, 17 January, 2003 1:06 pm
To: Stefan Hanenberg; aspectj-users@xxxxxxxxxxx; Jim.Hugunin@xxxxxxxx
Subject: Re: [aspectj-users] Intertype Declaration for only one target ?!?!?!?


> public void VisitedElement+.accept(Visitor v) {v.visit(this);}

Why? This is equivalent to:

> public void VisitedElement.accept(Visitor v) {v.visit(this);}

(no plus). Children of VisitedElement inherit the accept method normally.

In the case of inheritance heirarchies, "Type+" is often functionally
equivalent to "Type". For patterns like (Foo || Bar) then the static type
of  this becomes very confusing.

> It just says something like "this is at
> least of type ...".

I agree, but I am willing to live with this (firm) guarantee since *I*
control the members of the type. In the case of (Foo || Bar) I don't see
how AspectJ can make any (coherent) guarantees about the type of this.

Cheers,
Nick

--- Stefan Hanenberg <shanenbe@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
> Me again,
> 
> Lesiecki Nicholas wrote:
> 
> > I like the limitation personally. Consider:
> > 
> > public int Employee+.foo = 10;
> 
> yes, but consider:
> 
> public void VisitedElement+.accept(Visitor v) {v.visit(this);}
> 
> Great! Using more than one target for an introduction is not always that
> bad....
> 
> I doubt that the benefit of restricting member-introductions to only one
> target is such a help as expected. In fact it confuses the type-system
> somehow. The intention is, that the static type of "this" can be
> determined at compile-time. However.........in fact the limitation does
> NOT determine the static type. It just says something like "this is at
> least of type ...".
> 
> So transforming the code above to:
> 
>   public void VisitedElementInterface.accept(Visitor v) {v.visit(this);}
>   declare parents: (MyTree+) implements VisitedElementInterface;
> 
> does _not_ mean (if I understand it right and in case this code still
> works) that "this" has the static type "VisitedElementInterface", but
> "at least VisitedElementInterface". 
> 
> -Stefan
> 
> PS: I (shortly) discussed the binding of this in my AOSD'03 paper.
> Yes.....I think it is necessary to restrict the "anarchical usage of
> introductions" somehow. But my personal opinion is, that the usage of
> traditional interfaces for the purpose of typechecking is not the right
> way (....just a personal opinion).
> 
> PSPS (@Jim): Still scared....but not that much......;-)

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
_______________________________________________
aspectj-users mailing list
aspectj-users@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-users