2013/5/13 Emmanuel Bourg <ebo...@apache.org> > 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? >
+1 from a user POV why should you ever use the impl that is not smart or improved ;-) > > Emmanuel Bourg > > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter