2015-03-26 15:56 GMT+01:00 Steve Ebersole :
> I'm not so convinced that we need this additional level of instantiation
> just to avoid exposing access to the collected sources (getters).
>
Few things are strictly needed in the end :)
IMO limiting the exposed API as much as possible is a good thi
I'm not so convinced that we need this additional level of instantiation
just to avoid exposing access to the collected sources (getters).
Anyone else have opinions on this?
On Thu, Mar 26, 2015 at 3:35 AM, Gunnar Morling
wrote:
> 2015-03-26 3:56 GMT+01:00 Steve Ebersole :
>
>> On second though
2015-03-26 3:56 GMT+01:00 Steve Ebersole :
> On second thought...
>
> MetadataBuilder is also an interface (unless you are suggesting to change
> that for some reason), so not sure how a call like this would work:
>
> MetadataBuilder.defineSources()
>
Ah, I forgot you cannot rely on Java 8 yet ;)
2015-03-26 0:21 GMT+01:00 Steve Ebersole :
> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling
> wrote:
>
>> > 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?
>>
>> I
>
>
>> * Are MetadataSources#addAttributeConverter(),
>> addAuxiliaryDatabaseObject() and addSqlFunction() adding a *source* for
>> meta-data really? Somehow it seems they should rather be located on
>> MetadataBuilder?
>>
>
> From one perspective yes. Not *sources* per-se, but they are things tha
On second thought...
MetadataBuilder is also an interface (unless you are suggesting to change
that for some reason), so not sure how a call like this would work:
MetadataBuilder.defineSources()
On Wed, Mar 25, 2015 at 6:21 PM, Steve Ebersole wrote:
> On Wed, Mar 25, 2015 at 4:57 PM, Gunnar
On Wed, Mar 25, 2015 at 4:57 PM, Gunnar Morling
wrote:
> > 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?
>
> I think the split makes sense, as I understand that there ar
> 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?
I think the split makes sense, as I understand that there are two different
"phases" of configuration here:
* add multiple sour
On Wed, Mar 25, 2015 at 12:20:27PM -0500, Steve Ebersole wrote:
> I can get behind that.
>
> Anyone else?
+1
--Hardy
pgpsAu_1TGhVe.pgp
Description: PGP signature
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/ma
I can get behind that.
Anyone else?
On Wed, Mar 25, 2015 at 11:28 AM, Gunnar Morling
wrote:
> 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 para
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.
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
12 matches
Mail list logo
