We're updating the issue view to help you get more done. 

Search 6 groundwork - Replace bridge builders with *binders*

Description

The building process of bridges is currently as follows:

  • a builder is instantiated

  • its initialize() method is called, passing the annotation as a parameter

  • its build() method is called, returning a bridge

  • the bridge's bind() method is called, passing the binding context as a parameter.

It's a bit complex, and more importantly it implies that bridges are mutable until their bind() method is called.

We could probably simplify this by using "binders" instead of "builders".

  • a binder is instantiated

  • its initialize() method is called, passing the annotation as a parameter

  • its bind() method is called, passing the binding context as a parameter. The method returns the bridge instance. Any "optional" data returned by the binder (field type for value bridges, in particular) is returned through the binding context.

Advantages:

  • It's simpler: one fewer step

  • It's cleaner: the bridges become completely immutable, since the bind() method on bridges disappears.

  • It does not have to be more verbose: binder implementors can simply pass the context to the constructor of their bridge, and move to that constructor what they previously did in the bind() method.

  • It's more flexible: binders can pick a bridge implementation based on the binding context, for example based on the property type...

  • It solves the problem of how to pass "parameters" (see HSEARCH-3608): we would pass them to the binder directly, through an "initialize" method.

Cons:

  • It may require one interface per bridge type. Things could get complicated if we consider we also need one sub-interface to support annotations. Maybe we should expose a non-generic initialize(Annotation) method on all binders, with a default implementation that throws an exception?

  • We may need to add generics to the binder interfaces. For example to make sure that a ValueBridge binder only ever declares a field type that is consistent with the F parameter of the returned bridge.

  • Value bridges referenced by their type, without a builder/binder, can no longer define a custom type. Since that's advanced usage, I would argue it's reasonable to require a binder.

Environment

None

Status

Assignee

Yoann Rodière

Reporter

Yoann Rodière

Components

Fix versions

Priority

Major