Re: [aspectj-users] How to remove "abstract" with AspectJ?

[Ichthyostega <prg@xxxxxxxxxxxxxxx>]

Andy Clement schrieb:
> How would AspectJ know which meaning you had attached to 'abstract'? (whether
> it had your meaning, or it had mine which is to prevent people creating
> instances of the type)  If I don't know the users intent with specifying
> abstract in the source, I don't know if it is safe to 'promote' to being
> non-abstract simply if you have supplied implementations of all the abstract
> methods within it.

Hi,

honestly, that idea makes me feel a bit queasy. Usually, the original author
not only wants to express (or communicate) something with using abstract,
like "use it according to a certain pattern".

Often an "upstream" author of a library even assumes the precise and complete
behaviour of plain-java "abstract". Which means for example, the intention is
for the client to write its own implementation and use some factory mechanism
to inject this dedicated implementation.

Hendy Irawan schrieb:

> @NameableMixin2
> public abstract class Project implements Nameable { }

> The rationale of using abstract & implements is to avoid need of:

> ((Nameable))project).getName()

> and just use:
>   project.getName()

> @NameableMixin2 implemented using @AspectJ-notation aspect:


...so in this case, actually calling class Project "abstract" isn't intended to
express anything, rather we want to trick the compiler into accepting the
"implements Nameable" for the time being, until the real implementation is added
with the Help of AspectJ.

So why are we trying to play tricks with the compiler? Why are we trying to
subvert the language? When re-considering it, it seems to me that actually it's
the *creation* of the Project class or subclass, which causes the problems!
Java (as pretty much any statically typed language of that kind) is very
limited, when your intention is to *assemble* the *nature* of a class in
a dynamic fashion.

But why then not just trying to circumvent the problematic "new Project()" call?

In a similar situation I helped myself with a static factory method on the
abstract class (here "Project"). This method would return a Project instance
and it is implemented, but just to throw an
RuntimeException("need the help of AspectJ");
with an around-execution advice you could then inject an suitably assembled and
pre-configured subclass to provide the complete implementation. And using cflow,
you could even react on the specific usage context of that factory method.

Cheers,
Hermann Vosseler