A little pointcut help please

[matthewadams12]

Hi all,

Java has fused the concept of "namespace" and "component" in its
concept of "package".  This results in having to mark public things
that you really don't want public consumers to access.  .NET actually
fixes this with its "protected internal" scope:  only code from within
the current assembly can access the member scoped as protected
internal.

Now, I have a declare error statement attempting to achieve
functionality similar to C#'s "protected internal" scope, whereby only
code from within the current package is allowed to access the thing
that is annotated with @ProtectedInternal.

Here is my annotation & my declare error statement, but I'd like to
make it more general, replacing "org.foo.model.*" with something more
general that implies that access is disallowed from code that is
outside the called/accessed element's package, that is, not in the
annotated element's package.

@Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
                ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
public @interface ProtectedInternal {}
===============
public aspect ProtectedInternalDeclareError {
        declare error :
                (!within(org.foo.model.*)) // TODO:  replace this hardcoding with
something more general
                        && (set(@ProtectedInternal * *)
                                || get(@ProtectedInternal * *)
                                || call(@ProtectedInternal * *(..))
                                || call(* (@ProtectedInternal *..*).*(..))
                                || call(@ProtectedInternal *.new(..))
                                || call((@ProtectedInternal *).new(..))
                )
                : "The target constructor, method, or field is not designed for
public consumption; access is disallowed.";
}

Help, anyone?

Thanks,
Matthew
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Wim Deblauwe]

What is the difference between what you want to do here and "package protected" that is standard in java (e.g. not using private, protected or public modifiers) ?

regards,

Wim

2009/10/8 Matthew Adams <matthew@...>

Hi all,

Java has fused the concept of "namespace" and "component" in its
concept of "package".  This results in having to mark public things
that you really don't want public consumers to access.  .NET actually
fixes this with its "protected internal" scope:  only code from within
the current assembly can access the member scoped as protected
internal.

Now, I have a declare error statement attempting to achieve
functionality similar to C#'s "protected internal" scope, whereby only
code from within the current package is allowed to access the thing
that is annotated with @ProtectedInternal.

Here is my annotation & my declare error statement, but I'd like to
make it more general, replacing "org.foo.model.*" with something more
general that implies that access is disallowed from code that is
outside the called/accessed element's package, that is, not in the
annotated element's package.

@Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
               ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
public @interface ProtectedInternal {}
===============
public aspect ProtectedInternalDeclareError {
       declare error :
               (!within(org.foo.model.*)) // TODO:  replace this hardcoding with
something more general
                       && (set(@ProtectedInternal * *)
                               || get(@ProtectedInternal * *)
                               || call(@ProtectedInternal * *(..))
                               || call(* (@ProtectedInternal *..*).*(..))
                               || call(@ProtectedInternal *.new(..))
                               || call((@ProtectedInternal *).new(..))
               )
               : "The target constructor, method, or field is not designed for
public consumption; access is disallowed.";
}

Help, anyone?

Thanks,
Matthew
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

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

[G Balaji]

Some parts of this message have been removed. Learn more about Nabble's security policy.

I think the difference is that package-protected classes are visible only to members of the same package. They're not visible to members of a different package of the same assembly (assembly is the term the OP used; I think JAR would be the appropriate analogy here).

In any case, I think the OSGi bundles' manifest specification has solved this for Java components/applications. Only what is exposed through the bundle's manifest is visible/usable outside the bundle. In other words, all un-exposed classes are "protected internal".

With AspectJ, I think we need some classloader magic to effect this (same as what OSGi does??), or, AspectJ supports something like a "within(<ClassLoaderHierarchy>)" expression.

Thanks,
Balaji

---

From: Wim Deblauwe <wim.deblauwe@...>
To: aspectj-users@...
Sent: Fri, October 9, 2009 12:00:58 PM
Subject: Re: [aspectj-users] A little pointcut help please

What is the difference between what you want to do here and "package protected" that is standard in java (e.g. not using private, protected or public modifiers) ?

regards,

Wim

2009/10/8 Matthew Adams <matthew@...>

Hi all,

Java has fused the concept of "namespace" and "component" in its
concept of "package".  This results in having to mark public things
that you really don't want public consumers to access.  .NET actually
fixes this with its "protected internal" scope:  only code from within
the current assembly can access the member scoped as protected
internal.

Now, I have a declare error statement attempting to achieve
functionality similar to C#'s "protected internal" scope, whereby only
code from within the current package is allowed to access the thing
that is annotated with @ProtectedInternal.

Here is my annotation & my declare error statement, but I'd like to
make it more general, replacing "org.foo.model.*" with something more
general that implies that access is disallowed from code that is
outside the called/accessed element's package, that is, not in the
annotated element's package.

@Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
               ElementType.CONSTRUCTOR })
@Retention(RetentionPolicy.RUNTIME)
public @interface ProtectedInternal {}
===============
public aspect ProtectedInternalDeclareError {
       declare error :
               (!within(org.foo.model.*)) // TODO:  replace this hardcoding with
something more general
                       && (set(@ProtectedInternal * *)
                               || get(@ProtectedInternal * *)
                               || call(@ProtectedInternal * *(..))
                               || call(* (@ProtectedInternal *..*).*(..))
                               || call(@ProtectedInternal *.new(..))
                               || call((@ProtectedInternal *).new(..))
               )
               : "The target constructor, method, or field is not designed for
public consumption; access is disallowed.";
}

Help, anyone?

Thanks,
Matthew
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

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

[matthewadams12]

within(<ClassLoaderHierarchy>) would be nice, but that would require
OSGi (I think) and wouldn't solve my current problem.

My question stands.  Anyone?

On Thu, Oct 8, 2009 at 11:52 PM, Gopinathan Balaji
<gopinathanbalaji@...> wrote:

>
> I think the difference is that package-protected classes are visible only to
> members of the same package. They're not visible to members of a different
> package of the same assembly (assembly is the term the OP used; I think JAR
> would be the appropriate analogy here).
>
> In any case, I think the OSGi bundles' manifest specification has solved
> this for Java components/applications. Only what is exposed through the
> bundle's manifest is visible/usable outside the bundle. In other words, all
> un-exposed classes are "protected internal".
>
> With AspectJ, I think we need some classloader magic to effect this (same as
> what OSGi does??), or, AspectJ supports something like a
> "within(<ClassLoaderHierarchy>)" expression.
>
> Thanks,
> Balaji
>
> ________________________________
> From: Wim Deblauwe <wim.deblauwe@...>
> To: aspectj-users@...
> Sent: Fri, October 9, 2009 12:00:58 PM
> Subject: Re: [aspectj-users] A little pointcut help please
>
> What is the difference between what you want to do here and "package
> protected" that is standard in java (e.g. not using private, protected or
> public modifiers) ?
>
> regards,
>
> Wim
>
> 2009/10/8 Matthew Adams <matthew@...>
>>
>> Hi all,
>>
>> Java has fused the concept of "namespace" and "component" in its
>> concept of "package".  This results in having to mark public things
>> that you really don't want public consumers to access.  .NET actually
>> fixes this with its "protected internal" scope:  only code from within
>> the current assembly can access the member scoped as protected
>> internal.
>>
>> Now, I have a declare error statement attempting to achieve
>> functionality similar to C#'s "protected internal" scope, whereby only
>> code from within the current package is allowed to access the thing
>> that is annotated with @ProtectedInternal.
>>
>> Here is my annotation & my declare error statement, but I'd like to
>> make it more general, replacing "org.foo.model.*" with something more
>> general that implies that access is disallowed from code that is
>> outside the called/accessed element's package, that is, not in the
>> annotated element's package.
>>
>> @Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
>>                ElementType.CONSTRUCTOR })
>> @Retention(RetentionPolicy.RUNTIME)
>> public @interface ProtectedInternal {}
>> ===============
>> public aspect ProtectedInternalDeclareError {
>>        declare error :
>>                (!within(org.foo.model.*)) // TODO:  replace this
>> hardcoding with
>> something more general
>>                        && (set(@ProtectedInternal * *)
>>                                || get(@ProtectedInternal * *)
>>                                || call(@ProtectedInternal * *(..))
>>                                || call(* (@ProtectedInternal *..*).*(..))
>>                                || call(@ProtectedInternal *.new(..))
>>                                || call((@ProtectedInternal *).new(..))
>>                )
>>                : "The target constructor, method, or field is not designed
>> for
>> public consumption; access is disallowed.";
>> }
>>
>> Help, anyone?
>>
>> Thanks,
>> Matthew
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[matthewadams12]

If you use interfaces within a package, the methods on the interfaces
must be public, even if those interfaces will only be used within the
package (as in our design).  When classes within the package implement
those interfaces, their methods are necessarily public.

That means that any code can call it.  That's why I'd like the
equivalent of .NET's "protected internal".

On Thu, Oct 8, 2009 at 11:30 PM, Wim Deblauwe <wim.deblauwe@...> wrote:

> What is the difference between what you want to do here and "package
> protected" that is standard in java (e.g. not using private, protected or
> public modifiers) ?
>
> regards,
>
> Wim
>
> 2009/10/8 Matthew Adams <matthew@...>
>>
>> Hi all,
>>
>> Java has fused the concept of "namespace" and "component" in its
>> concept of "package".  This results in having to mark public things
>> that you really don't want public consumers to access.  .NET actually
>> fixes this with its "protected internal" scope:  only code from within
>> the current assembly can access the member scoped as protected
>> internal.
>>
>> Now, I have a declare error statement attempting to achieve
>> functionality similar to C#'s "protected internal" scope, whereby only
>> code from within the current package is allowed to access the thing
>> that is annotated with @ProtectedInternal.
>>
>> Here is my annotation & my declare error statement, but I'd like to
>> make it more general, replacing "org.foo.model.*" with something more
>> general that implies that access is disallowed from code that is
>> outside the called/accessed element's package, that is, not in the
>> annotated element's package.
>>
>> @Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
>>                ElementType.CONSTRUCTOR })
>> @Retention(RetentionPolicy.RUNTIME)
>> public @interface ProtectedInternal {}
>> ===============
>> public aspect ProtectedInternalDeclareError {
>>        declare error :
>>                (!within(org.foo.model.*)) // TODO:  replace this
>> hardcoding with
>> something more general
>>                        && (set(@ProtectedInternal * *)
>>                                || get(@ProtectedInternal * *)
>>                                || call(@ProtectedInternal * *(..))
>>                                || call(* (@ProtectedInternal *..*).*(..))
>>                                || call(@ProtectedInternal *.new(..))
>>                                || call((@ProtectedInternal *).new(..))
>>                )
>>                : "The target constructor, method, or field is not designed
>> for
>> public consumption; access is disallowed.";
>> }
>>
>> Help, anyone?
>>
>> Thanks,
>> Matthew
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[matthewadams12]

BTW, now that I think about it, even in OSGi, I'm not sure this solves
my problem, because OSGi bundles export packages, not individual
classes or methods, and my problem exists at the method visibility
level across several classes within the package.

On Thu, Oct 8, 2009 at 11:52 PM, Gopinathan Balaji
<gopinathanbalaji@...> wrote:

>
> I think the difference is that package-protected classes are visible only to
> members of the same package. They're not visible to members of a different
> package of the same assembly (assembly is the term the OP used; I think JAR
> would be the appropriate analogy here).
>
> In any case, I think the OSGi bundles' manifest specification has solved
> this for Java components/applications. Only what is exposed through the
> bundle's manifest is visible/usable outside the bundle. In other words, all
> un-exposed classes are "protected internal".
>
> With AspectJ, I think we need some classloader magic to effect this (same as
> what OSGi does??), or, AspectJ supports something like a
> "within(<ClassLoaderHierarchy>)" expression.
>
> Thanks,
> Balaji
>
> ________________________________
> From: Wim Deblauwe <wim.deblauwe@...>
> To: aspectj-users@...
> Sent: Fri, October 9, 2009 12:00:58 PM
> Subject: Re: [aspectj-users] A little pointcut help please
>
> What is the difference between what you want to do here and "package
> protected" that is standard in java (e.g. not using private, protected or
> public modifiers) ?
>
> regards,
>
> Wim
>
> 2009/10/8 Matthew Adams <matthew@...>
>>
>> Hi all,
>>
>> Java has fused the concept of "namespace" and "component" in its
>> concept of "package".  This results in having to mark public things
>> that you really don't want public consumers to access.  .NET actually
>> fixes this with its "protected internal" scope:  only code from within
>> the current assembly can access the member scoped as protected
>> internal.
>>
>> Now, I have a declare error statement attempting to achieve
>> functionality similar to C#'s "protected internal" scope, whereby only
>> code from within the current package is allowed to access the thing
>> that is annotated with @ProtectedInternal.
>>
>> Here is my annotation & my declare error statement, but I'd like to
>> make it more general, replacing "org.foo.model.*" with something more
>> general that implies that access is disallowed from code that is
>> outside the called/accessed element's package, that is, not in the
>> annotated element's package.
>>
>> @Target( { ElementType.TYPE, ElementType.METHOD, ElementType.FIELD,
>>                ElementType.CONSTRUCTOR })
>> @Retention(RetentionPolicy.RUNTIME)
>> public @interface ProtectedInternal {}
>> ===============
>> public aspect ProtectedInternalDeclareError {
>>        declare error :
>>                (!within(org.foo.model.*)) // TODO:  replace this
>> hardcoding with
>> something more general
>>                        && (set(@ProtectedInternal * *)
>>                                || get(@ProtectedInternal * *)
>>                                || call(@ProtectedInternal * *(..))
>>                                || call(* (@ProtectedInternal *..*).*(..))
>>                                || call(@ProtectedInternal *.new(..))
>>                                || call((@ProtectedInternal *).new(..))
>>                )
>>                : "The target constructor, method, or field is not designed
>> for
>> public consumption; access is disallowed.";
>> }
>>
>> Help, anyone?
>>
>> Thanks,
>> Matthew
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>
>
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>
>

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andrew Eisenberg]

Hi Matthew,

I don't know how much control you have over the code you are trying to
enforce API usage on, but OSGi + Eclipse's API tooling might be a help
here:
http://wiki.eclipse.org/ApiTools_Architecture

Essentially, the API tooling allows you to add JavaDoc tags (yes,
Eclipse internals are still using 1.4, so no annotations) that
describe how other plugins can consume classes in the current plugin.
Eg- @noreference, @noimplement, @noextend, etc.

On Sat, Oct 10, 2009 at 7:19 AM, Matthew Adams <matthew@...> wrote:
> BTW, now that I think about it, even in OSGi, I'm not sure this solves
> my problem, because OSGi bundles export packages, not individual
> classes or methods, and my problem exists at the method visibility
> level across several classes within the package.
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[matthewadams12]

Well, that might help, but answering the question in the first message
of this thread will do nicely for now:

At the line commented with GENERALIZE ME, I'd like to replace a
hard-coded type expression with one that effectively means "not within
the package of the thing (field, method, constructor or class)
annotated with @ProtectedInternal".

public aspect ProtectedInternalDeclareError {
       declare error :
               (!within(org.foo.model.*)) // GENERALIZE ME
                       && (set(@ProtectedInternal * *)
                               || get(@ProtectedInternal * *)
                               || call(@ProtectedInternal * *(..))
                               || call(* (@ProtectedInternal *..*).*(..))
                               || call(@ProtectedInternal *.new(..))
                               || call((@ProtectedInternal *).new(..))
               )
               : "The target constructor, method, or field is not designed for
public consumption; access is disallowed.";
}

I just realized that there's a bug in my pointcut -- I'm not
supporting the prevention of accessing any fields whose class is
annotated with @ProtectedInternal.  How would I add that one, too?

Thanks,
Matthew

On Sat, Oct 10, 2009 at 8:05 PM, Andrew Eisenberg <andrew@...> wrote:

> Hi Matthew,
>
> I don't know how much control you have over the code you are trying to
> enforce API usage on, but OSGi + Eclipse's API tooling might be a help
> here:
> http://wiki.eclipse.org/ApiTools_Architecture
>
> Essentially, the API tooling allows you to add JavaDoc tags (yes,
> Eclipse internals are still using 1.4, so no annotations) that
> describe how other plugins can consume classes in the current plugin.
> Eg- @noreference, @noimplement, @noextend, etc.
>
> On Sat, Oct 10, 2009 at 7:19 AM, Matthew Adams <matthew@...> wrote:
>> BTW, now that I think about it, even in OSGi, I'm not sure this solves
>> my problem, because OSGi bundles export packages, not individual
>> classes or methods, and my problem exists at the method visibility
>> level across several classes within the package.
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[Andy Clement]

Hi Matthew,

> I just realized that there's a bug in my pointcut -- I'm not
> supporting the prevention of accessing any fields whose class is
> annotated with @ProtectedInternal.  How would I add that one, too?

set((@ProtectedInternal *) *) || get((@ProtectedInternal *) *)

But the 'of the thing' part of your description makes it hard to
specify the within in a general way.  Obviously you can do it with a
runtime test in some advice (or perhaps with an if() clause) but that
prevents you using declare error.  I can't think of how else to do it
- maybe someone else can?

But it doesn't seem entirely unreasonable - you just want the advise
to be conditional on different properties of the same join point  I
wouldn't be against exploring what we can do here in the language with
a few changes.  I don't know what those changes would be however -
perhaps we can do more static interpretation of if() clauses:
if(!thisEnclosingJoinPoint.getPackage().equals(thisJoinPoint.getPackage))
or similar.

Andy


2009/10/12 Matthew Adams <matthew@...>:

> Well, that might help, but answering the question in the first message
> of this thread will do nicely for now:
>
> At the line commented with GENERALIZE ME, I'd like to replace a
> hard-coded type expression with one that effectively means "not within
> the package of the thing (field, method, constructor or class)
> annotated with @ProtectedInternal".
>
> public aspect ProtectedInternalDeclareError {
>       declare error :
>               (!within(org.foo.model.*)) // GENERALIZE ME
>                       && (set(@ProtectedInternal * *)
>                               || get(@ProtectedInternal * *)
>                               || call(@ProtectedInternal * *(..))
>                               || call(* (@ProtectedInternal *..*).*(..))
>                               || call(@ProtectedInternal *.new(..))
>                               || call((@ProtectedInternal *).new(..))
>               )
>               : "The target constructor, method, or field is not designed for
> public consumption; access is disallowed.";
> }
>
> I just realized that there's a bug in my pointcut -- I'm not
> supporting the prevention of accessing any fields whose class is
> annotated with @ProtectedInternal.  How would I add that one, too?
>
> Thanks,
> Matthew
>
> On Sat, Oct 10, 2009 at 8:05 PM, Andrew Eisenberg <andrew@...> wrote:
>> Hi Matthew,
>>
>> I don't know how much control you have over the code you are trying to
>> enforce API usage on, but OSGi + Eclipse's API tooling might be a help
>> here:
>> http://wiki.eclipse.org/ApiTools_Architecture
>>
>> Essentially, the API tooling allows you to add JavaDoc tags (yes,
>> Eclipse internals are still using 1.4, so no annotations) that
>> describe how other plugins can consume classes in the current plugin.
>> Eg- @noreference, @noimplement, @noextend, etc.
>>
>> On Sat, Oct 10, 2009 at 7:19 AM, Matthew Adams <matthew@...> wrote:
>>> BTW, now that I think about it, even in OSGi, I'm not sure this solves
>>> my problem, because OSGi bundles export packages, not individual
>>> classes or methods, and my problem exists at the method visibility
>>> level across several classes within the package.
>> _______________________________________________
>> aspectj-users mailing list
>> aspectj-users@...
>> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>>
>
>
>
> --
> mailto:matthew@...
> skype:matthewadams12
> yahoo:matthewadams
> aol:matthewadams12
> google-talk:matthewadams12@...
> msn:matthew@...
> http://matthewadams.me
> http://www.linkedin.com/in/matthewadams
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@...
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
>

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

[matthewadams12]

inline

On Tue, Oct 13, 2009 at 7:34 AM, Andy Clement <andrew.clement@...> wrote:
> Hi Matthew,
>
>> I just realized that there's a bug in my pointcut -- I'm not
>> supporting the prevention of accessing any fields whose class is
>> annotated with @ProtectedInternal.  How would I add that one, too?
>
> set((@ProtectedInternal *) *) || get((@ProtectedInternal *) *)
>
Ah, yes.  Thanks.

> But the 'of the thing' part of your description makes it hard to
> specify the within in a general way.  Obviously you can do it with a
> runtime test in some advice (or perhaps with an if() clause) but that
> prevents you using declare error.  I can't think of how else to do it
> - maybe someone else can?
>
> But it doesn't seem entirely unreasonable - you just want the advise
> to be conditional on different properties of the same join point  I
> wouldn't be against exploring what we can do here in the language with
> a few changes.  I don't know what those changes would be however -
> perhaps we can do more static interpretation of if() clauses:
> if(!thisEnclosingJoinPoint.getPackage().equals(thisJoinPoint.getPackage))
> or similar.
>

Yes, this would be quite nice.  I think there were other static
pointcut enhancements that I came across but can't remember right now.
 I'll add an issue with this one, and if I (or anyone) can think of
any, they can add it to the issue.

Thanks,
Matthew
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users

[matthewadams12]

Bug filed.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=292262

On Wed, Oct 14, 2009 at 6:56 AM, Matthew Adams <matthew@...> wrote:

> inline
>
> On Tue, Oct 13, 2009 at 7:34 AM, Andy Clement <andrew.clement@...> wrote:
>> Hi Matthew,
>>
>>> I just realized that there's a bug in my pointcut -- I'm not
>>> supporting the prevention of accessing any fields whose class is
>>> annotated with @ProtectedInternal.  How would I add that one, too?
>>
>> set((@ProtectedInternal *) *) || get((@ProtectedInternal *) *)
>>
> Ah, yes.  Thanks.
>
>> But the 'of the thing' part of your description makes it hard to
>> specify the within in a general way.  Obviously you can do it with a
>> runtime test in some advice (or perhaps with an if() clause) but that
>> prevents you using declare error.  I can't think of how else to do it
>> - maybe someone else can?
>>
>> But it doesn't seem entirely unreasonable - you just want the advise
>> to be conditional on different properties of the same join point  I
>> wouldn't be against exploring what we can do here in the language with
>> a few changes.  I don't know what those changes would be however -
>> perhaps we can do more static interpretation of if() clauses:
>> if(!thisEnclosingJoinPoint.getPackage().equals(thisJoinPoint.getPackage))
>> or similar.
>>
> Yes, this would be quite nice.  I think there were other static
> pointcut enhancements that I came across but can't remember right now.
>  I'll add an issue with this one, and if I (or anyone) can think of
> any, they can add it to the issue.
>
> Thanks,
> Matthew
>

--
mailto:matthew@...
skype:matthewadams12
yahoo:matthewadams
aol:matthewadams12
google-talk:matthewadams12@...
msn:matthew@...
http://matthewadams.me
http://www.linkedin.com/in/matthewadams
_______________________________________________
aspectj-users mailing list
aspectj-users@...
https://dev.eclipse.org/mailman/listinfo/aspectj-users