API issues

[Gustavo Niemeyer]

> > A few bzrlib API issues that have made implementing something based on
> > top of it a little tricky.
> > 
> > smart_add_branch() is great, we can pass in a branch object and a
> > reporter callback function and get the feedback we need.  Though it
> > feels wrong calling a separate function -- could this not be bzrlib.add
> > itself?
> 
> I think Branch is the wrong layer for DWIM.  If you want to do this, I'd
> much rather see it in a SmartBranch class that delegated to a branch
> member.  That way, the branch API is simpler and easier to reimplement.

That'd be nice. We could even use the WorkingBranch class me and Scott
have been working on as a starting point. It implements a few interesting
details which could be desirable in a higher level interface.

> Frankly, I think your feeling about functions is wrong.  They're a
> well-proven tool.  Just because objects are good doesn't mean functions
> are bad.

Functions are not bad at all, but using many different approaches
creates inconsistencies, and this is undesirable. Currently, we have
the add.smart_add() function which calls the Branch.add() class/method,
but no remove.smart_remove() and no remove.py at all. OTOH, we do have
commit.py, and we have the Branch.commit() class/method which actually
calls the commit.commit() function blindly (no arg check), and the later
is a one liner which calls the Commit().commit() class/method blindly
again.

This is looking a bit uncomfortable, IMO. Of course, bzr is just being
born, but taking care to avoid expanding this, and even fixing the
style when possible, would certainly be a plus.

-- 
Gustavo Niemeyer
http://niemeyer.net