search

m-m-m / util

Mature Modular Meta-Framework
http://m-m-m.sourceforge.net
Apache License 2.0
10 stars 5 forks source link

Difficulties to discover the needed API for accessors #126

Closed maybeec closed 9 years ago

maybeec commented 10 years ago

I currently try to solve the problem stated in #125 and I had the following problems while discovering the introspection API:

The accessor modes should be easily accessible, e.g., to get an accessor of a specific mode. Currently, the PojoDescriptor#getAccessor methods specify a parameter mode to be set of type PojoPropertyAccessorMode<ACCESSOR>. Nevertheless, it is not possible to easily access valid instances for this parameter as the static accessible fields are classified in different subclasses like PojoPropertyAccessorNonArgMode.

Two valid solutions:

  1. It would be easier for the API user if there were a class, which makes all modes available via a single interface. Normally someone might try the callee's class or the parameter's class as a source for static fields to be inserted as valid parameters. None of this cases is implemented.
  2. In order to not refactor all this stuff, you might want to provide additional JavaDoc to list the different static fields, which will be considered as valid accessors in your current implementation.
hohwille commented 10 years ago

Thanks for the feedback. Actually dealing with accessors is quite an advanced use-case. There is a high-level API with e.g. PojoDescriptor.getProperty(POJO pojo, String property)

The accessors need to have different types for generic correctness and interleaving. However, it might be a good idea for 1. to have a central type offering all available modes (the idea was that modes can also be implemented outside mmm-util-core and plugged into for really advanced use-cases) or at least for 2. to list them in the javadoc. I think already 1. is a good option and would also solve 2.

hohwille commented 9 years ago

Adding the available constants to PojoPropertyAccessorMode would be intuitive for first view of API users. However, this is sick as the constants would be inherited by all subclasses so every extended mode class would have them and mix arbitrary modes together and also shadow the ones it actually defines. The only reasonable way to address this is IMHO to add a new type PojoPropertyAccessorModes in the same package defining all the constants in one place.

hohwille commented 9 years ago

Done. Hope it suites your expectations.