[hibernate-dev] SessionFactory building APIs

[Gunnar Morling]

2) What do you think of all the overloaded methods named #with tacking
different argument types, versus distinctly named methods?

I find it sub-optimal as it falls apart if there are several parameters of
the same type (e.g. String or boolean). This leads to some irregularities
in the names, e.g. atm. there is withImplicitSchemaName(String),
withImplicitCatalogName(String) but then with(PhysicalNamingStrategy).

Personally, I'd do implicitSchemaName(String), implicitCatalogName(String),
physicalNamingStrategy(PhysicalNamingStrategy) etc. i.e. just the name of
the property to set.

2015-03-21 19:09 GMT+01:00 Steve Ebersole <steve at hibernate.org>:

> I had not heard anything back in regards to this, so I wanted to ask one
> more time before I get ready to start cutting 5.0 pre-releases in a week or
> 2.
>
> I'd love to heard feedback of any kind about the new APIs, but specific
> things I know I personally question:
>
> 1) What do you think of the split in MetadataSources and MetadataBuilder?
> Does the aplit make sense?  Or does it make more sense to combine them into
> one contract?
>
> 2) What do you think of all the overloaded methods named #with tacking
> different argument types, versus distinctly named methods?  E.g.
> MetadataBuilder#with(ImplicitNamingStrategy),
> MetadataBuilder#with(PhysicalNamingStrategy), etc rather than
> MetadataBuilder#withImplicitNamingStrategy(ImplicitNamingStrategy),
> MetadataBuilder#withPhysicalNamingStrategy(PhysicalNamingStrategy)
>
> Also, I am not so sure about the term "with" anymore.  I had chosen that at
> the time because I thought it flowed nicely with method chaining.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>