Hi, I haven't followed the discussion around "reflite" closely, so I'm just going to add some thoughts/questions coming to my mind after exploring the model a bit:
* Is there some sort of design document which describes at a higher level the purpose and the benefit of the model? If not, e.g. JavaDocs on the package level (or one of the new topical guides) would be great for that. * What is the primary motivation for having this model, is it about ease-of-use or performance (through Jandex) compared to using plain reflection, or something else? * The "reflite" model remembers me a bit of the one in javax.lang.model.type.* [1]. So if the aim of "reflite" is to provide a "complete" model which can represent each and every specific of the Java type system, it might make sense to implement this pre-defined model (it's all interfaces) based on Jandex/ClassMate instead of defining a custom model. But if we're only interested in a specific sub-set of the Java type-model, having a custom model probably is the better choice as it provides a simpler-to-use contract (and it may allow for a "domain-specific" language, e.g. by working with concepts such as "entity" instead of the generic "Java type"). * Regarding a "collapsed" representation of type information (as done by java.lang.Class) vs. a hierarchy of specialized types, I think it depends on the usage patterns. With the current approach, how are clients supposed to take action depending on the specific type of a descriptor (if they have a reference to the super-type of the hierarchy)? Via instanceof calls? The javax model API provides a (rather verbose) visitor approach as well as method getKind() for this (so the latter is basically instanceof). --Gunnar [1] http://docs.oracle.com/javase/8/docs/api/index.html?javax/lang/model/type/package-summary.html 2014-06-03 12:51 GMT+02:00 Hardy Ferentschik <ha...@hibernate.org>: > > On 2 Jan 2014, at 18:36, Steve Ebersole <st...@hibernate.org> wrote: > > > 1) What do you think of the split in JavaTypeDescriptor into distinct > > sub-contracts? For example, the split between say ClassDescriptor and > > InterfaceDescriptor? > > Didn’t we have this discussion before. If I remember correctly you were > the one who favoured the > current model. What made you change your mind. > > > TBH, I am starting to rethink that one. What about > > primitive versus non-primitive descriptors? Etc… > > Unfortunately, I did not actually write code against the API yet, so I > don’t have any concrete experience. > On paper it looks good to me. But it seems you encountered something which > creates an itch? > > > 2) Overall what do you think about the API itself? > > for what i have seen and what we discussed, it is the way to go. I can see > me using this type of model > in other Hibernate projects as well. > > —Hardy > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
