Hello 2015-01-13 10:27 GMT+01:00 Tresch, Anatole <[email protected]>: > Hi all > > I have a couple of questions regarding the current state: > > > 1) In Java 7 we have introduced a ConfigurationProvider, which is > necessary, since static methods on interfaces are not supported by Java 7. In > Java 8 we introduced the according Configuration.current(). I would in that > case deprecate ConfigurationProvider, since its only there for backward > compatibility and basically not needed anymore. Agreed? >
-0, for me provider != current() - even if it is the default. It is really a factory impl IMO and makes sense even in j8 otherwise you mix concerns between context and provider IMO. > 2) As discussed shortly on our last hangout, I have added ConfigOperator > and ConfigQuery which are normal interfaces in Java 7, but usable as > functional interfaces in Java 8. This is needed since java.util.function is > not available on Java 7. > > 3) Currently PropertyConverter is currently a functional interface, which > basically is nice, but there are a couple of reasons I think, it requires > additional methods: > > a. there is already a comment to add a method on the provider that returns > examples of the formats supported, so error messages and exceptions can > easily be filled with more explicit information on the formats effectively > supported by the converters registered. > > b. Currently different converters can be priorized by adding a @Priority > annotation. Nevertheless the ConfigurationContext has not information about > the target type a converter is supported, due to runtime type erasure. Since > I think, trying every converter available for each type is very ineffective > and error prone, I would suggest an additional method as follows: > Class<T> getTargetType(); > This would easily allow to manage the different converters by the regarding > target type. PropertyConverter instances then would be registered for the > target type and all its super-types, except Object. So a converter for > MySpecialBigDecimal would similarly also be usable for BigDecimal (which > MySpecialBigDecimal extends). > WDYT? > Take care handling the hierarchy, it can create conflicts where actually there is no conflicts at all + that's not cause you know how to handle a car that you can hanle a vehicle properly. In between solution would be to use a weight between converter type and current type and use the smaller but I find it very complicated for cases I think rare. That said linking a converter to a type is quite mandatory (using getTargetType() or rather register(Type type, Converter converter)) > Anatole > > > > Anatole Tresch > Platform Strategy & Strategic Projects, KGVX 42 > +41 44 334 03 89 (*414 0389) >
