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

[Hardy Ferentschik]

On 1 Jan 2014, at 22:55, Gunnar Morling <gunnar at hibernate.org> wrote:

> 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
> 
> 
> 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