Sorry, had Evolution problems (still in the primordial ooze :)) and this
didn't get sent.
On Tue, 2004-12-07 at 07:50, C. Michael Pilato wrote:
> VK Sameer <sameer@collab.net> writes:
>
> > OK, I'm open to suggestions :) If it helps any, the first comment is
> > going to go away partially as per Philip Martin's and Peter Lundblad's
> > comments.
>
> Yeah, I think someone else suggested that simply defining what a valid
> path is would do the trick (instead of detailing the algorithm for
> detecting invalid ones).
[I'm still trying to decide whether to answer each email and repeat or
consolidate and risk losing part of the thread info somewhere.]
OK, have changed as per Karl's suggestion.
> I'm a big fan of APIs that list every return value, but haven't the
> time or energy to retroactively do this for Subversion. That said,
> we are pretty good about listing return codes that we anticipate
> callers explicitly testing for. I anticipate callers testing the
> return value of this function (beyond just "is errorful").
There are 2 functions now, one that just returns a boolean value and
another that returns an error, again per Karl's suggestion.
> In fact, since the goal of the function is to answer a question -- "Is
> this path a valid Subversion path?" -- we may instead want this
> interface to take an svn_boolean_t * parameter which is populated with
> TRUE or FALSE to yield the answer, and leave all error conditions to
> mean, "Something bad happened that prevents me from answering your
> question." Besides a better semantic feel, this would also prevent
> Subversion from instantiating an error that the caller might choose
> not to use (and have to tear down).
Makes sense. I think having 2 functions as mentioned above covers your
points?
> > > Also, we don't generally pass lengths with our paths.
> >
> > I can remove that if that is the general policy.
>
> Yep, that's the general policy.
OK, done.
Sameer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Dec 10 06:07:07 2004