On 13 May 2013 21:30, Emmanuel Bourg <ebo...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
