Extend java static meta model accessors

[andreas-schilling]

Fixes #515

[andreas-schilling]

While I consider the PR to be fine as it is, there is also an alternative way to implement this.
The accessor method could be extracted to its own interface

public interface PropertyAccessor<C, T> {
   T getValue( C object );
}

so that the static property changes to

public abstract class StaticProperty<C, T> extends DefaultProperty implements PropertyAccessor<C, T>

This doesn't change much in a first stage, however if we think a bit further into the direction of chained properties, computed properties or other ad-hoc defined metamodel elements (either at compile- or at runtime), this would allow writing static-like code also on non-static metamodel elements, that might have been dynamically loaded during runtime.

This could be handy when operating on certain properties in a truly generic application scenario where the meta information of some part is known to the developer (like "I want to operate on a property that represents a temperature measurement, independent from the Aspect/Entity surrounding it and I also don't even know what meta model elements I get hold of while the application runs").
I know that this is a tad abstract and also only gains the same amount of type safety when it is implemented using runtime checks that guarantee, that the implemented bits can only be applied to data that actually matches the ad-hoc meta information.
Still, the change as of now would be rather small and I could adjust the PR accordingly.

WDYT?

[atextor]

While I consider the PR to be fine as it is, there is also an alternative way to implement this. The accessor method could be extracted to its own interface

public interface PropertyAccessor<C, T> {
   T getValue( C object );
}

so that the static property changes to

public abstract class StaticProperty<C, T> extends DefaultProperty implements PropertyAccessor<C, T>

This doesn't change much in a first stage, however if we think a bit further into the direction of chained properties, computed properties or other ad-hoc defined metamodel elements (either at compile- or at runtime), this would allow writing static-like code also on non-static metamodel elements, that might have been dynamically loaded during runtime.

This could be handy when operating on certain properties in a truly generic application scenario where the meta information of some part is known to the developer (like "I want to operate on a property that represents a temperature measurement, independent from the Aspect/Entity surrounding it and I also don't even know what meta model elements I get hold of while the application runs"). I know that this is a tad abstract and also only gains the same amount of type safety when it is implemented using runtime checks that guarantee, that the implemented bits can only be applied to data that actually matches the ad-hoc meta information. Still, the change as of now would be rather small and I could adjust the PR accordingly.

WDYT?

I like the idea of having this and I'd be fine with both approaches, adjusting this PR or create a new one with this change. I approved this PR as-is and I leave it up to you if you'd like to change it again or rather create a separate one. The only thing I'd ask for in addition would be some user documentation (in java-aspect-tooling.adoc) that explains how to use this feature.

[github-actions]

Release v2.5.1 addresses this.