On 2010-03-16 16.20, Philippe Van Dyck wrote:
I don't think that the current solution is a bad one, I actually like it, but if qi4j had a "pojo like" interface, with annotations, it should be simpler to learn and to integrate.
No, then you will have two things to do the same thing. Not necessarily easier. Just more confusing.
When I see how project lombok generates accessors with annotations, It may be a good idea to generate qi4j compliant lazy loading, metadata-full, ones.
I tried code generation in a previous life (XDoclet). Not tempted to go back to it...
I am talking about some kind of pojo layer surrounding *current* implementation.
What's the usecase?
It may also be a good way to write a petclinic sample to ease the comparison to spring or other technologies.
Now, that I can buy. I agree that the DDD sample code that we have now should be updated to use the idioms we have found in the StreamFlow project. My problem is time, of which there is little.
Again, it is all about the learning curve... but imagine your reddev sample code with ... less code and no strange get() and set() accessors (only used by qi4j!?).... and going from a pojo DCI implementation to a pojo with qi4j's annotations DCI implementation. Qi4j position seems to be "the only way to do DCI in java", what about "the easy way to do DCI in java" ;-)
Well... the thing is that in terms of cognitive load and learning, is it easier to learn "you gotta do @Property on your fields and then stuff will be generated for you", or "Declare a property with Property<X> name();". Or worse, "pick which one you like", for no good reason.
If we were to start from scratch today we could evaluate whether to use fields with annotations instead of the current Property<X> style, but that's not the case. And I don't want to have two ways to do pretty much the same thing. That will be too confusing.
/Rickard _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
