Re: [aspectj-dev] Fwd: static context/pointcuts (was [aspectj-users] Obj

["Ramnivas Laddad" <ramnivas@xxxxxxxxxxxxxxx>]

Consider a more typical use of this(). Binding this to null (or the
class object) will make it difficult to write advice and pointcuts.
For example, currently I can write:

after(Account acc) returning : execution(* Account.set*(..)) && this(acc) {
   acc.setDirty();
}

Instead of:

after(Account acc) returning : execution(* Account.set*(..)) && this(acc) {
   if (acc != null) {
      acc.setDirty();
   }
}

or

after(Account acc) returning : execution(!static * Account.set*(..))
&& this(acc) {
   acc.setDirty();
}

Essentially, every advice will have to either checks for null or
ensure that pointcut uses !static. Given that in a good software
system static method are far fewer, the current design guarantees that
'this' may never be null exactly like in Java is helpful.

Can you describe the use cases where this() binding to null would
simplify programming? Perhaps, there may be a solution within the
current language design.

-Ramnivas

On Tue, Dec 16, 2008 at 7:53 PM, Eric Tanter <etanter@xxxxxxxxxxxxx> wrote:
> Thanks Ramnivas for replying.
>
> I understand your point about the simplicity of the "this() binds the this
> object", vs. having to say "this() binds the this object, or null if the jp
> occurs in a static context".
>
> But, arguably, this would still be simpler than having to explain why one
> needs to write his pointcuts twice (if context is exposed), when a single
> set of pointcuts does the job when no context is used.
>
> -- Éric
>
>
> On Dec 16, 2008, at 20:40 , Ramnivas Laddad wrote:
>
>> The problem with binding this() to null or the class object is that it
>> breaks the simplicity of saying "this() binds the this object". Since
>> with static methods, this doesn't even exist, the current behavior can
>> be explained (agreed to or not :-)). Had Java made a different choice
>> (especially binding the class to this in a static method), I am sure
>> AspectJ would have the choice you suggest.
>>
>> -Ramnivas
>>
>> On Tue, Dec 16, 2008 at 2:30 PM, Eric Tanter <etanter@xxxxxxxxxxxxx>
>> wrote:
>>>
>>> Hi all,
>>>
>>> My post (below) on aspectj-users has not triggered any reaction.
>>> I'm wondering whether on aspectj-dev it would.
>>>
>>> Apologies if the question has been asked and answered before -- in that
>>> case, please point me to the appropriate place.
>>>
>>> Thanks,
>>>
>>> -- Éric
>>>
>>>
>>> Begin forwarded message:
>>>
>>>> From: Eric Tanter <etanter@xxxxxxxxxxxxx>
>>>> Date: December 12, 2008 3:07:30  GMT-03:00
>>>> To: aspectj-users@xxxxxxxxxxx
>>>> Subject: Re: [aspectj-users] Object Graph using aspectj
>>>> Reply-To: aspectj-users@xxxxxxxxxxx
>>>>
>>>> On Dec 12, 2008, at 14:58 , Andy Clement wrote:
>>>>>
>>>>> If you are using this()/target() to bind context, be aware that they
>>>>> will
>>>>> not match in a static context (this() wont match when the join point
>>>>> occurs
>>>>> within a static method for example, and there is no target() if a call
>>>>> is to
>>>>> a static method).  In these cases you need two sets of pointcuts, one
>>>>> set to
>>>>> handle the static case and one to handle the non-static case.
>>>>
>>>> Just wondering:
>>>>
>>>> Why not following Java's way of dealing with the fact that classes are
>>>> not
>>>> true objects? ie. one uses null for the this object in a reflective
>>>> static
>>>> method invocation -- so this()/target() could expose null, no?
>>>>
>>>> That would avoid this kind of ad-hoc non-uniformity. It is quite odd
>>>> that
>>>> just by exposing context, one needs to double his pointcut definitions.
>>>>
>>>> (of course a nicer alternative would be to really pass the class object
>>>> as
>>>> being the target/this, but that may be too much to ask for ;)).
>>>>
>>>> -- Éric_______________________________________________
>>>> aspectj-users mailing list
>>>> aspectj-users@xxxxxxxxxxx
>>>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>>
>>> _______________________________________________
>>> aspectj-dev mailing list
>>> aspectj-dev@xxxxxxxxxxx
>>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>>>
>> _______________________________________________
>> aspectj-dev mailing list
>> aspectj-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>
> _______________________________________________
> aspectj-dev mailing list
> aspectj-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-dev
>