commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [DBUTILS] Pre RC for DBUTILS-2.0
Date Mon, 13 May 2013 20:34:03 GMT
On 13 May 2013 21:30, Emmanuel Bourg <ebourg@apache.org> wrote:
> Le 13/05/2013 21:24, William Speirs a écrit :
>>
>> Yes, I did mean QueryExecutor... sorry. I make my methods protected rather
>> than private because I'm not sure how someone (maybe myself) will need to
>> change functionality in the future. If I make them private, then there's
>> not going back. If I make them protected, someone can always extend and
>> provide new functionality. I'm open to other suggestions/ideas though.
>
> Actually it's the opposite. With protected methods there is no going
> back. Binary compatibility dictates that these methods will stay there
> forever, you won't be able to refactor them unlike private methods. You
> can still relax the constraint later by making them protected or public
> if the need arises.

+1

>
>> Yes... but to what advantage?
>
> The advantage is an API that is cleaner and easier to understand.
>

+1

>
>> It is more "generous" in finding a matching name in the bean for a column.
>> It will try to remove underscores from column names to match bean names.
>> Maybe a better name would/could be UnderscoreAgnosticBeanHandler, but I
>> think the idea was to eventually extend GenerousBeanProcessor to include an
>> array (or string) of single characters that could be replaced/removed in an
>> attempt to find a match. I don't think this needs to be a blocker though to
>> get 2.0 out the door. I'll update the JavaDocs though.
>
> Some examples in the Javadoc would help.
>
> As for the name, what about "SmartBeanProcessor" or
> "ImprovedBeanProcessor" (much like the ImprovedNamingStrategy in
> Hibernate) ? If this implementation is much better than the one in
> BeanProcessor, maybe it could be merged with BeanProcessor to be used by
> default?
>
> Emmanuel Bourg
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message