P.S. I've been slowly but surely trying to fix up any and all checkstyle errors/warnings found over the past few weeks. (I think close to a couple thousand have been cleared out now). Tweaks to this shared configuration would also help keep me in line.
On 4/9/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > Yeah, sorry. Think I'm the guilty party again on this one :) Initially I > was very frustrated with this coding style while doing tacos work, but have > now found that it has saved me a lot of pain when trying to change the > render cycle. > > I've traditionally preferred protected members by default, unless I knew > that there just wasn't any possible reason why someone should have access to > it or that anyone messing with it would screw things up. > > I should probably go read up on that article that Geoff pointed out ( > http://www.eclipse.org/eclipse/development/java-api-evolution.html) as my > experience developing API's that affect thousands vs tens of developers is > pretty much non existant. > > > On 4/9/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > We probably need to discuss coding style issues. > > > > For instance, a lot of the new code I'm looking at is using protected > > instance variables. I favor private instance variables in almost all > > cases, even when I'm designing a class to be extended ... but then I > > provide protected or public accessor methods to those private fields. > > > > What I haven't done in Tapestry or HiveMind, but am starting to do in > > Tapestry5, is to use "final" much more liberally. But that's another > > discussion. > > > > In addition, a note about HiveMind services and Log. > > > > If you have a writable property named "log" (i.e. setLog() is the > > setter method name), and the type is org.apache.commons.logging.Log , > > then HiveMind will autowire that property to a Log instance based on > > the *service* name (not the implementation class name). This is > > actually a function of the default service factory, > > hivemind.BuilderFactory . > > > > This is good for testing, since its easier to provide a mock > > implementation of Log than to deal with the Log created by the class > > for itself (the traditional approach). > > > > > > > > -- > > Howard M. Lewis Ship > > Independent J2EE / Open-Source Java Consultant > > Creator, Jakarta Tapestry > > Creator, Jakarta HiveMind > > > > Professional Tapestry training, mentoring, support > > and project work. http://howardlewisship.com > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Jesse Kuhnert > Tacos/Tapestry, team member/developer > > Open source based consulting work centered around > dojo/tapestry/tacos/hivemind. http://opennotion.com > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
