On Wed, Jan 29, 2003 at 08:22:26PM -0500, Garrett Rooney wrote:
On Wednesday, January 29, 2003, at 07:53 PM, Greg Stein wrote:
...
i could go either way on this. keeping it opaque seemed like a
reasonable idea so that we could easily add new things to it in the
future (post-1.0) while still remaining binary compatability, but
realistically, if we're adding new callbacks or something keeping
binary compatability might be pointless if we're breaking semantic
compatability.
...
Why the whole error thing? Just return NULL. It could be quite a valid
approach for the caller to want to check if auth stuff has been
installed or
not. They shouldn't have to deal with error returns.
as i start playing with the notification baton, it is getting more and
more annoying having the error return, since having a null notification
function/baton is completely valid. i'm definately leaning towards
forgetting about the error and just returning null if there isn't
anything set.
Cool.
Basically, it seems like there is too much engineering around what
could
be a simple structure.
i'm still not sure if it's worth leaving this opaque or not. is their
any advantage in being able to change this later while retaining binary
compatability?
You mention binary compatibility here and above. You may have missed a point
that I made: the context would be opaque *outside* of libsvn_client, but
visible *inside*. You don't have to be binary compat for inside things. If
you make a change to the context, then you're upgrading the library, which
means that you're also updating all uses of the non-opaque structure.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 14 02:24:53 2006