Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re[2]: [aspectj-users] Once again aboutn non-this access

Hello Wes,


Thank you very much for your response.

WI> You can use within(), but it doesn't really help.

WI> A join point has a signature specifying only types, so
WI> it seems like a dynamic test is needed.

With dynamic check such feature has completely no sense.
The only reason of this my request is optimization of preprocessed
code. In good OO programs instance variables are usually accessed only
by self or derived classes. Access to foreign variables is not
recommended (better to use setter/getter methods). In Smalltalk such
access is not even possible! Now lets see what's happen if I want to
implement persistence or remoting aspect. The main idea is
transparently load target object. As far as Java is not
Smalltalk nobody can prevent programmer from accessing instance
variable of other objects. So I insert before access to the field
code performing loading of the object. But for self instance variable
this code is absolutely useless - self object is already loaded.
And as far as access to self instance variable happens most frequently
(in well designed program as I said it is 100%), been not able to
distinguish self and not-self access cause significant performance and
byte code size overhead. Concerning your example, I already mentioned
in my previous mail that exact check (that != this) is not
needed: I just want to avoid generation of extra code for normally
accessed instance variables. It will cause completely no problems if value
of target reference is equal to this.

Still wonder why nobody else request this feature before - size of
code and will be significantly decreased and performance - increased
(not extra method call for each field access). I think that is very
important for production applications based on AspectJ.

WI> Assuming the join point signature were changed to include
WI> an attribute for the invoking reference indicating
WI> whether it was directly (but explicitly or implicitly)
WI> via "this", consider

WI>     class Foo {
WI>         int i;
WI>         Bar o;
WI>         int incBoth(Foo foo) {
WI>            return (i++ + foo.i++); // foo:foo==this?
WI>         }
WI>         int incMe() {
WI>            return incBoth(this);
WI>         }
WI>         int incMeAgain() {
WI>            Foo me  = this;        // not a join point
WI>            return incBoth(me);
WI>         }
WI>         public String toString() {
WI>            Bar p = (o == null ? Bar.CONST : o);
WI>            return p.toString();
WI>         }
WI>     }

WI> If it were supported, it would seem arbitary and
WI> would hide the real semantics, which are dynamic.
WI> So to me it looks impractical and more confusing than
WI> helpful.

WI> Wes

WI> P.S. - As for whether this is the right place or whether
WI> anyone replies to a message, that is all purely consensual.
WI> No one is obliged to answer anyone's email.  There is
WI> a general obligation on the part of the committers to
WI> participate in discussions on aspectj-dev pertaining to
WI> the *development* of the technology, but aspectj-users is
WI> for users to communicate with each other.  If people
WI> require immediate support when writing AspectJ code,
WI> they can solicit professional support here or on
WI> aspectj-dev.  (It's generally considered improper for
WI> those offering support services to solicit people who
WI> post to mailing lists unless the posters explicitly
WI> request professional support.)  Also, emails on
WI> questions that can't be resolved by considering the
WI> documentation tend to spark more interest, as do emails
WI> from posters who in the past have contributed correct
WI> and well- written questions and answers.

WI> Konstantin Knizhnik wrote:

>> Hello,
>> 
>> Three days ago I have sent the question to this mailing list about
>> possibility to distinguish access to this and foreign
>> objects with AspectJ pointcuts. I received no replies to my message.
>> I wonder if this mailing list is the right place for asking such
>> questions? Its it really checked by Aspect-J developers?
>> 
>> I briefly repeat my message here. To be able to efficiently implement
>> persistence and remoting aspects, it will be very useful to be able to
>> distinguish access to self instance fields and access to fields of
>> other objects (non-this access). In last case, such accesses should be
>> wrapped with advice code which is responsible for object loading.
>> But there is completely no need to insert such code for access to self
>> instance variables. Right now I find only one way how to express
>> correspondent pointcut in AspectJ: comparing result of this() and
>> target(). But it is translated by AspectJ in runtime check! So it is
>> in any case impossible to avoid AOP overhead for accessing self
>> instance fields.
>> 
>> Actually what I want to know
>> 1. Is such feature currently supported by Aspect-J?
>> 2. If not - what is the reason:
>> - nobody requested such feature before
>> - technical problems with implementing this feature (it seems to me
>> that there are completely no problems)
>> - some ideological arguments against adding this feature
>> - this feature will not be used by most of Aspect-J users
>> - performance is not critical for most of Aspect-J users.
>> 3. Also are there plans to implement it in 1.2 version of Aspect-J?
>> 

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



-- 
Best regards,
 Konstantin                            mailto:knizhnik@xxxxxxxxx



Back to the top