Like gunnar, I was thinking that a type property and an unwrapping
method would do the trick. Though I'd favor delegation over
subclassing.
On Tue 2013-07-16 9:27, Gunnar Morling wrote:
> Hi,
>
> > I won't mention my favorite Vattern. I've considered adding subtypes
> but not liking it as their usage would not be clear from the API.
>
> How would you use your vavorite Vattern without subtypes? And which other
> option would you prefer then?
>
> I think the field-type specific information can either be on
>
> a) FieldSettingsDescriptor itself (as is today)
> b) specific subtypes of FSD
> c) specific delegates of FSD, safely accessible via a type parameter of FSD
>
> a) would IMO be the simplest but could lead to a proliferation of
> attributes on FSD; So as you say it depends on the number of specific
> attributes whether its feasible or not. But even if sticking to this
> approach, we might consider to replace boolean isNumeric() with FieldType
> getFieldType(). This would avoid adding a new isXy() method for each
> specific type and be used like so:
>
> if ( desc.fieldType = NUMERIC) {
> doSomething( desc.precisionStep() );
> else if ( desc.fieldType = FOO ) {
> doSomething( desc.fooAttrib() );
> }
>
> For b), you need a way to narrow down to the subtype, either via Visitor or
> some kind of cast. I still find this pattern as used in BV reads quite
> nicely:
>
> Object result = null;
> if ( desc.fieldType = NUMERIC) {
> result = doSomething( desc.as(
> NumericDescriptor.class).precisionStep()
> );
> else if ( desc.fieldType = FOO ) {
> result doSomething( desc.as( FooDescriptor.class).fooAttrib() );
> }
>
> In particular, as() would only accept subtypes of Descriptor and be thus a
> bit safer than a plain downcast.
>
> Btw., the annotation processing API (as e.g. used by the Meta model
> generator or the AP in Hibernate Validator), offers both ways for that
> purpose, i.e. a visitor approach and, getKind() + downcast. Having worked
> with both, I find the usually simpler to use.
>
> For a comparison, the last example would look like this with a visitor
> design similar to the annotation processing API (the type parameters are
> for parameter and return type passed to/retrieved from the visitor):
>
> Object result = desc.accept(
> new FieldDescriptorVisitor<Void, Object>() {
>
> @Override
> Object visitAsNumber(NumberDescriptor descriptor, Void p) {
> return doSomething( descriptor.precisionStep() );
> }
>
> @Override
> Object visitAsFoo(FooDescriptor descriptor, Void p) {
> return doSomething( descriptor.fooAttrib() );
> }
> }
> );
>
> Personally, I find this reads and writes not as nice as the other approach.
>
> Regarding c), one could think of something like this:
>
> class FieldSettingsDescriptor<T extends DescriptorSpecifics> {
> public T getSpecifics();
> ...
> }
>
> and
>
> FieldSettingsDescriptor<NumberSpecifics> numberDescriptor = ...;
> doSomething( numberDescriptor.getSpecifics().precisionStep() );
>
> But the question is how one would obtain a properly typed descriptor. E.g.
> from a collection with mixed fields, one would only get
> FieldSettingsDescriptor<?>, making this quite pointless.
>
> I think, I'd like the getType()/as() approach best. Or do you have yet
> another approach in mind?
>
> --Gunnar
>
>
>
> 2013/7/15 Sanne Grinovero <sa...@hibernate.org>
>
> > The new FieldSettingsDescriptor [1] has a couple of methods meant for
> > Numeric fields:
> >
> > /**
> > * @return the numeric precision step in case this field is indexed as
> > a numeric value. If the field is not numeric
> > * {@code null} is returned.
> > */
> > Integer precisionStep();
> >
> > /**
> > * @return {@code true} if this field is indexed as numeric field,
> > {@code false} otherwise
> > *
> > * @see #precisionStep()
> > */
> > boolean isNumeric();
> >
> > Today we have specific support for the
> > org.apache.lucene.document.NumericField type from Lucene, so these are
> > reasonable (and needed to build queries) but this specific kind is
> > being replaced by a more general purpose encoding so that you don't
> > have "just" NumericField but can have a wide range of special fields.
> >
> > So today for simplicity it would make sense to expose these methods
> > directly on the FieldSettingsDescriptor as it makes sense for our
> > users, but then also the #isNumeric() is needed as not all fields are
> > numeric: we're having these extra methods to accommodate for the needs
> > of some special cases.
> >
> > Considering that we might get more "special cases" with Lucene4, and
> > that probably they will have different options, would we be able to
> > both decouple from these specific options and also expose the needed
> > precisionStep ?
> >
> > I won't mention my favorite Vattern. I've considered adding subtypes
> > but not liking it as their usage would not be clear from the API.
> >
> > Cheers,
> > Sanne
> >
> > 1 - as merged two minutes ago
> > _______________________________________________
> > 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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
