I think I'm okay so long as AbstractBinder and BuilderHelper contain all
the functionality I need, and I don't need to mix the two styles. I now
believe that AbstractBinder has everything I need so I guess I'll stick
to that; BuilderHelper contains most of the same functionality but if I
recall correctly, some things are a little harder to bind (e.g.
factories). I still think that we need to reduce the number of classes
involved here, but I guess that's something to revisit in the future.
Gili
On 03/12/2013 7:19 AM, John Wells wrote:
> It is true that we now have basically two separate EDSL, one in the
> org.glassfish.hk2.utilities.binding package and one in the
> org.glassfish.hk2.utilities package. If I had this to do over I would
> put the second one in its own package to distinguish it from the other
> dsl and other generic utilities. However, HK2 is at the point that we
> want to maintain backwards compatibility and hence we won't be
> changing packages at this time.
>
> I also agree that the org.glassfish.hk2.utilities.binding is not very
> well documented. That should be fixed. In theory if you are using
> classes and things from this package you should not need anything from
> the other package. (This is also true of the first EDSL). The
> org.glassfish.hk2.utilities.binding is more like a "fluent" api, while
> the other EDSL is "fluent-like" since it does not keep state and you
> need to "finish" the descriptor yourself with a call to "build" or
> "buildFactory". I think which one you like better is a matter of style.
>
> If you enter a Jira asking for better documentation on the two EDSL
> styles I will be sure to remember to write that documentation (one day).
>
> I think that the DynamicConfiguration class is directly responsible
> for holding descriptors to be added or removed from the system. It
> does handle some very simple cases (maybe it should not) but in
> general its job is different from a generic Descriptor builder. I can
> see adding a method there specifically for constants, although at this
> point I think it is a better idea to just leave it as is. Lets
> enhance the other builders to make them more useable, since the
> DynamicConfiguration class really has a different purpose.
>
> On 12/2/2013 5:45 PM, cowwoc wrote:
>> Hi,
>>
>> I'm attempting to migrate code from Guice to HK2. I wanted to share
>> an outsider's point of view on the API.
>>
>> While I appreciate how much more powerful HK2's binding model is than
>> Guice, I find it to be a total mess for basic use-cases.
>>
>> I found the following classes related to binding:
>>
>> * Binder
>> * AbstractBinder
>> * BuilderHelper
>> * AbstractBindingBuilder
>> * Descriptor
>> * DescriptorImpl
>> * AbstractActiveDescriptor
>>
>> and there are others. It seems I'm not the only one who is confused.
>> See http://stackoverflow.com/q/17396165/14731 and
>> http://stackoverflow.com/a/20128336/14731.
>>
>> What makes it worse is that some functionality is available one
>> class, but other functionality is available in another class (e.g.
>> bindFactory() in AbstractBinder but
>> BuilderHelper.createConstantDescriptor() for constants). Many of
>> these classes add very little code before redirecting to one another.
>> Please refactor all this functionality under the DynamicConfiguration
>> class and hide all the implementation details under the hood.
>>
>> I ran into this problem while trying to solve three simple use-cases:
>>
>> * Binding of type to constant/instance, with qualifier, in scope.
>> * Binding of a Factory
>> * Binding of a JSR 330 Provider
>>
>> Thanks,
>> Gili
>>
>