On 10/1/07, Daniel Rall <email@example.com> wrote:
> On Mon, 01 Oct 2007, Joe Swatosh wrote:
> > On 10/1/07, Daniel Rall <firstname.lastname@example.org> wrote:
> > > Why does proplist take a depth parameter, while propget and propset
> > > take a recurse parameter (e.g. backwards compat)?
> > Looks like I screwed it up months ago:
> > ================================
> > Revision: 25019
> > Author: joeswatosh
> > Date: 11:13:50 PM, Monday, May 14, 2007
> > Message:
> > Follow on to r25007 which added depth support to svn_client_proplist3.
> > * subversion/bindings/swig/ruby/svn/client.rb
> > (Svn::Client::Context#proplist) changed argument name and default to
> > reflect the use of depth instead of recurse in the core API.
> > Reviewed by: kou
> > dlr
> That doesn't look so screwed up...
> > I think you're on to something in the other thread. Probably all
> > (proplist, propset and propget) should take a 'recurse_or_depth'
> > parameter that we should turn into a depth before we pass along. I
> > think that way we can turn a True or False into the depth we want.
> > Especially since it may not always match SVN_DEPTH_FROM_RECURSE in
> > every case.
> ...especially once we have something like this, which sounds good.
> We'll need two varieties of svn_swig_rb_to_depth(), for selecting
> between the non-recursive mode of empty vs. files, similar to the way
> we have both a SVN_DEPTH_FROM_RECURSE() and
> SVN_DEPTH_FROM_RECURSE_STATUS() macros -- the latter of which needs to
> be renamed to something more generic -- in the core libraries.
I'm not sure how we'd select between the two varieties. Right now its
just based on the svn_depth_t in the signature of the function being
wrapped. Maybe we use a naming convention to signify which to use
instead of all the prototypes using 'depth' in the arg list? Seems
like it might be too much of a pain for the maintainers.... But if
they were willing to do it there might be other places where either a
naming convention or some sort of decoration could be put to good use
by the SWIG based bindings (I'm thinking of ALLOW_NULL or NEVER_NULL
sort of things for pointers, I'm sure there are others).
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Tue Oct 2 02:11:46 2007