On 02 Apr 2014, at 03:04, Sanne Grinovero <sanne(a)hibernate.org> wrote:
>> 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.
True, you could classify this as an "implementation error" .. but if I
where that developer I wouldn't be sure how to fix it, while a single
method API would have been straight forward.
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.
I don’t think you argument is relevant in this situation.
The situation you describe would also mean that we should guessType every time we need a
bridge rather than onces at startup. It would also mean that because of the shape of the
moon the application would boot or fail (see duplication logic). In other wiords, having
two methods would be the least of our problems :)