On 2 Jan 2014, at 03:04, Sanne Grinovero <sa...@hibernate.org> wrote:
> On 1 April 2014 21:19, Hardy Ferentschik <ha...@hibernate.org> wrote:
>>
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard <emman...@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
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
