[hibernate-dev] [HSEARCH] Autodiscoverable field bridges next steps

[Gunnar Morling]

2014-04-01 22:19 GMT+02:00 Hardy Ferentschik <hardy at hibernate.org>:

>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel at hibernate.org> wrote:
>
> > ## Splitting the BridgeProvider in two methods
> >
> > A way make the inelegant code structure
> >
> >    FieldBridge bridge = provider.provide(...);
> >    if ( bridge != null ) {
> >        return bridge
> >    }
> >
> > Is to ask of the provider to answer two question:
> >
> > - boolean canProvideBridgeFor(...)
> > - FieldBridge createFieldBridge(...)
> >
> > The code would become
> >
> >    if ( provider.canProvideBridgeFor(...) ) {
> >        return createFieldBridge(...)
> >    }
>
> I prefer the latter. I tried already all sorts of arguments on the pull
> requests, but it might be that I stand alone here.
> I think it is more intuitive since it avoids the null check and I almost
> can implement the provider without looking at the Javadocs
> telling my what to do. Also in the real world, you would first ask me
> whether I can make you something, before telling me to do so, right?
>
> One of the counter arguments I've heard is, that having two methods
> instead of one creates some code duplication in the implementation.
> I find this a weak argument. If I look at the API I first look at what I
> want this API to do and how it should do it. Whether the impl needs to
> repeat
> some piece of code is a different question. And if nothing else, the
> implementation can extract the common code into a method.
>
> > Another concern is that if the answer to can... and create... are
> inconsistent, we are in trouble.
>
> Well, if canProvideBridgeFor returns true it should create the bridge when
> provide is called. Unless there is of course an (runtime) error when
> creating
> the bridge. However, this would throw an exception. If the bridge provider
> does not behave this way, you have indeed a bug, but I don't see the big
> difference
> to this type of bug to any other implementation error.
>

FWIW, I side with those preferring a single method and doing a null check.

It's mainly a matter of taste, but I feel it's easier to "forget" to invoke
the canProvide() method before calling create() than doing the null check.
I don't think a null check is something bad which should be avoided, but
it's rather the canonical idiom for dealing with option result values.

Also wouldn't create() have to do the check internally again to protect
against incorrect invocations and raise a proper exception? This would
imply a slight runtime overhead. For that reason I also prefer to access
hash maps via get() and check the result for null instead of using hasKey()
+ get().

--Hardy
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>