We further did a spike on creating instances of annotations to be able to add
them to metaInfo at startup time.
So, when we include that, we can do sth. like the following. (It's done by
creating a virtual Proxy for the annotation
interface - as no other way of instantiation works :)
on(Person.class).with().name().set(annotation(Immutable.class,"ignore",true))
so we not only can do it at composition (compile-)time but configure it later
as well.
We should but, make MetaInfo an interface, so that the runtime access only
allows getting the information
not changing it at runtime.
Regarding Immutable.ignore ->
on setting immutables you could either throw an RuntimeException or silently
ignore it.
With this boolean property you would change the default behaviour of throwing
an exception.
WDYT?
Perhaps we even can do the Annotation construction with
Immutable immutable=annotation(Immutable.class);
set(immutable.ignore()).to(false);
and so getting type-safety for the values set.
Michael, who enjoyed the geek cruise and coding/discussing with Rickard so much.
Rickard Öberg schrieb:
> Hey,
>
> This is the first mail on things that we talked about at the GeekCruise.
> More to follow, but not all at once, so that each thing can get the
> attention it deserves.
>
> Currently properties are declared by using a method in an interface, and
> the type of property can be either Property, ImmutableProperty or
> ComputedProperty. As has already been noted in some cases this makes it
> difficult to reuse property declarations, since whether they are
> immutable or not is sometimes a matter of context. If "HasName.name()"
> is part of an Entity it might be mutable, whereas the same property in a
> ValueComposite should be immutable.
>
> To alleviate this it was suggested that we instead only have Property as
> the interface and use annotations like @Immutable and @Computed to
> denote these things. It is also suggested that metaInfo() is populated
> with the annotations of the type it represents, such as Composite,
> Entity, Property or Association.
>
> For example, if you declare "@Immutable Property<String> name()" you can
> then do property.metaInfo(Immutable.class) and get the annotation back
> (or null). In addition to this, it is suggested that annotations are
> inherited, so that if you declare an annotation on an interface it is
> "leaked" to the methods/properties. That way you can do this:
> @Immutable
> interface PersonValue
> {
> Property<String> name();
> }
> and name() would then be an immutable property. This can be refactored to:
> @Immutable
> interface PersonValue
> extends HasName
> {}
>
> The individual HasName interface can then be used in both mutable and
> immutable contexts.
>
> Same reasoning then for @Computed, although it's going to be less useful
> to do the inheritance of it (maybe, although name() can actually be
> computed in some cases).
>
> What say ye? Michael did this refactoring on my computer (not
> committed), so from an implementation point of view it seems fine.
>
> /Rickard
>
>
>
> _______________________________________________
> qi4j-dev mailing list
> [email protected]
> http://lists.ops4j.org/mailman/listinfo/qi4j-dev
_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev
