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 <st...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
