Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jgit-dev] JGit Client API

On Tue, Apr 20, 2010 at 3:46 PM, Christian Halstrick <christian.halstrick@xxxxxxxxx> wrote:
Hi,

> The point is just that reporting errors when possible is better than
> nothing.
> There are other techniques with better guarantees: you could lazily store
...

I agree that with your suggestions it may be technically possible to
detect missing calls to a "run()" method. But on the other hand I am
not sure whether it is ok to spent so much effort in  detecting
adpotential misusage of the API.
And is it really always an error when people don't call "run()". What
is if developers produce common commands in advance (e.g. a command
"git log HEAD..master") so they can fire it whenever they need it by
just calling "run()". They would like to call "run()" multiple times
without producing new commands. Then we would always have prebuild
command which has not been executed. Even if we don't allow multiple
"run()" calls to one command a developer could build a new command and
just before he wants to call run() an he decides not call this command
anymore (e.g. an exception occurs).

All this make me think that we as API developer should not try to
detect this possible error situation.

Ciao
 Chris

It was just a suggestion and completely a matter of taste when building an API, I think.  I thought I'd provide another alternative, since Robin pointed out that finalization isn't guaranteed to be called.  Command builders are usually part of usability layers (something rather foreign to Sun and most of the JDK, unfortunately).  I like strong usability layers (I'm an old Smalltalk programmer).  The resources you put into building one can run from zero to overkill.  I tend to make layered toolkits (more towards overkill) rather than sparse frameworks (closer to zero and more like what you get from Sun).  I haven't contributed any code to JGit yet, so I don't expect to have much of a say in this, anyway :).


Bill

Back to the top