Re: [patch] ruby bindings tracking the recurse=>depth changes in svn_client_proplist3

Hi,

2007/5/15, Daniel Rall <dlr@collab.net>:

> > >FWIW, I like the use of an explicit value, as it makes the code more
> > >easy to understand.
> >
> > We use depth=nil as default value in other methods.
> > depth=nil means "we use default depth value" and the default
> > depth value is used all depth parameter. I think using depth=nil
> > for all methods is more understandable rather than using
> > depth=Core::DEPTH_INFINITY only for Svn::Client#proplist.
>
> Sure, I understand that nil equates to "use the default" -- that's a
> common pattern. I don't see how nil can be claimed as more
> comprehensible than an explicit value, however, when the latter is
> self-documenting, and the former isn't documented at all in the
> "end-user" API.

Yes. You're right. I'll do what you say if it doesn't affect API usage.
If there is a method like the following:

  def x(a, b, c=1, d=2, e=3)
    ...
  end

And I want to specify a, b, and d and use default value for c and e.
Then I'll want to write the following:

  x(1, 2, nil, 3)

But I can't do the above because I can't specify d without dropping
c argument. So I can't use default value for c.

But if x is defined as the following:

  def x(a, b, c=nil, d=nil, e=nil)
    c ||= 1
    d ||= 2
    e ||= 3
    ...
  end

I can specify d and use default value for c like the following:

  x(1, 2, nil, 3)

In this case, it's OK for me to change like the following:

  def proplist(target, rev=nil, peg_rev=nil, depth=nil, &block)
    ..
    depth ||= Core::DEPTH_INFINITY # or :infinity
    ...
  end

# I have a plan for improving API.
# I want to provide XXX2 methods their argument is hash.
# For example, we can use proplist like the following:
# ctx.proplist2(:target => "XXX", :depth => :infinity)

> Looks like you made a change in r25016 to support use of symbols in
> the underlying implementation?

No. I just noticed and implemented that. There is no more
meaning.

Thanks,

--
kou
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org