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

[Hardy Ferentschik]

On 2 Jan 2014, at 03:04, Sanne Grinovero <sanne at hibernate.org> wrote:

> On 1 April 2014 21:19, Hardy Ferentschik <hardy at hibernate.org> wrote:
>> 
>> 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?
> 
> Lol, I'm imagining you politely asking your dog to see if he has time
> to fetch your tablet :)

Different story. If I know she can do certain things, I just give her the command. Different pattern.

>> 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.
> 
> What I meant is that in certain situations the state of the
> underlaying service might change between invocations. Let's say your
> bridge implementor is configured via an external resource, containing
> like a list of things it's supposed to handle. Now let's assume that
> this can be reconfigured at runtime (crazy stuff which seems common in
> OSGi world, but also not too unusual via JMX): at one moment of time,
> your implementation could say "yes I can", and right after be forced
> to return null or throw an exception.

This sounds ways to o construed to me to even be worth considering.

> We might not expect these things to be configured at runtime, but we
> had several examples in which things which where expected to be quite
> "static" have later needed to be refactored in mutable things. If you
> take the MutableSearchFactory and our complex boot, I guess you
> immediatly see what kind of pain I'm referring to when we need to fix
> such an assumption in a second phase.

The pain of MutableSearchFactory is not so much the fact that we need to be able
to modify a SearchFactory, but that somewhere we went a bit overboard when implementing it.
I don’t see any connection between MutableSearchFactory and BridgeProvider whatsoever.

—Hardy