commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <>
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 <> 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.


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


>> 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:
For additional commands, e-mail:

View raw message