Re: [jgit-dev] JGit Client API

[Robin Rosenberg <robin.rosenberg@xxxxxxxxxx>]

måndagen den 19 april 2010 13.14.12 skrev  Bill Burdick:
> What about at least logging a message with the finalize method of the
> builder if you don't send that final message?
> 
> On Mon, Apr 19, 2010 at 4:56 AM, Shawn Pearce <spearce@xxxxxxxxxxx> wrote:
> > On Sun, Apr 18, 2010 at 1:13 PM, Christian Halstrick
> >
> > <christian.halstrick@xxxxxxxxx> wrote:
> > > And for me the next best alternative is option b) , the Builder
> > > proposal from Shawn. I would hate to be forced to explicitly
> > > instantiate <command>Options classes when just want to fire a simple
> > > git command with one parameter.
> >
> > Well, really common cases we can try to overload.  commit() to create
> > a builder, versus commit(String message) to create the builder, set
> > the message, and execute immediately with the rest of the data
> > assumed, just like `git commit -m message` behaves.  But we do have to
> > be careful, we can't overload too much.  I wouldn't suggest
> > overloading commit more than just the String message case, anything
> > else just gets to complex too fast.
> >
> > The only problem with the builder approach is, its easy to forget that
> > final verb method to fire the actual action.  With the more
> > traditional Java approach, that's less likely.  I still kind of prefer
> > it though, its easier to work with inside of an IDE where completion
> > is available based on context, and it can often produce shorter code
> > in the hands of a novice.  It also plays somewhat nicely with
> > dependency injection, since the library code controls construction of
> > the builders, not the user code.

Static analysis might be helpful. It should be possible to write a findbugs 
rule for the common usage pattern and distribute it with the library. Maybe 
there are other tools that are smart enough to see that no side effects are 
produce without special rules. This case is a bit harder than finding that a 
metod call is useless, since it has to look at all uses of a set of possible 
classes and methods to find out that no side effects are produced. 

-- robin