Yes, I think I agree that it was a mistake. Also try to recall that one thing that was considered at the time was to support Concerns on Property methods, and using Property subtypes was a path forward on that (although we never get to implement it).
On Fri, Jul 1, 2011 at 1:14 PM, Rickard Öberg <[email protected]> wrote: > Hi, > > In looking at things to simplify, I am now checking the support for Property > subtypes. Example: > @MaxLength( 50 ) > interface Name > extends Property<String> > { > } > --- > The idea here is that you can declare "Name name()" in many places, and it > will apply the same constraints, i.e. "it's a string property with max > length 50". > > When looking through the code I find two issues with this: > 1) It is REALLY hard to separate between the notion of "value" and "property > of value". One of the key usages, for example, is by Niclas in the logging > library, where he himself confuses this and so created a Property<LogType> > even though LogType is a property subtype already. A simple enum performed > the same task, but much clearer. > > 2) It is also not clear how clients are supposed to instantiate these for > setting the properties. With the above, you cannot really create a LogType > unless you first create a value with it, set it, and then take the > property-with-value from the LogType. But then taking it gets all > complicated when an Entity-internal LogType property is to be updated with a > LogType property coming from an external Value. Messy beyond belief. > > And so, there seems to be at least three better ways to accomplish what > Property subtypes were supposed to do: > 1) Use enums > 2) Use composite domain-specific constraints: > @ConstraintDeclaration > @Retention( RetentionPolicy.RUNTIME ) > @MaxLength(50) > public @interface Name {} > Which then is used as: > @Name Property<String> name(); > or in method calls: > void changeName(@Name String newName); > > 3) Create a ValueComposite: > interface Fullname > extends ValueComposite > { > @Name Property<String> givenName(); > @Name Property<String> surName(); > } > --- > > So, considering this I am therefore removing the support for Property > subtyping. This will also make it easier to see in code exactly what a > method is for ("Property<String> name()" is immediately identified as a > Property declaration, whereas "Name name()" isn't). > > I hope this is ok with everyone. > > /Rickard > > _______________________________________________ > qi4j-dev mailing list > [email protected] > http://lists.ops4j.org/mailman/listinfo/qi4j-dev > -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/3xugrbk I work here; http://tinyurl.com/24svnvk I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
