On 1 Jan 2014, at 22:55, Gunnar Morling <gunnar(a)hibernate.org> wrote:
2014-04-01 22:19 GMT+02:00 Hardy Ferentschik
<hardy(a)hibernate.org>:
On 1 Jan 2014, at 16:36, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
> ## Splitting the BridgeProvider in two methods
FWIW, I side with those preferring a single method and doing a null check.
It's mainly a matter of taste,
Sure, to a certain degree
but I feel it's easier to "forget" to invoke the
canProvide() method before calling create() than doing the null check.
But you don’t have to do it. If you as user want to provide a custom BridgeProvider you
just implement the interface.
It is up to us to make the right calls. What’s about a custom ConstraintValidator in Bean
Validation where you have initialise
ans isValid? The user does not need to call these methods himself and he cannot forget to
call initialise. Ensuring the right
order of calls is part of the Validator engine.
For me also Iterator#hasNext() and #next() comes to mind. Also a lot of Lucene interfaces
you can implement,
for example Collector or FieldComparator, have a very intricate interaction between the
Lucene engine and
the implementor of the interface.
I don't think a null check is something bad which should be
avoided,
sure you can do that, but you can also be more explicit.
Also wouldn't create() have to do the check internally again to
protect against incorrect invocations and raise a proper exception?
It could, but it is not a requirement.
This would imply a slight runtime overhead.
I don’t think this is an issue here. Bridge discovery is a bootstrapping thing which
happens once during the buildup of the SearchFactory.
Anyways, I guess I rest my case.
—Hardy