On Wednesday, January 29, 2003, at 08:50 PM, Philip Martin wrote:
Garrett Rooney rooneg@electricjellyfish.net writes:
Eek. This code is *inside* libsvn_client. Our typical pattern is
that a
structure is opaque outside the library, but completely visible
inside the library. Thus, we don't need to use getters/setters
within the
library. The code can simply refer to ctx-auth_baton.
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.
Binary compatability isn't really important here, but there is another
reason why you may want to keep it opaque and that's if anything gets
cached in the structure. For example, the svn_wc_adm_access_t access
baton is opaque to libsvn_wc, it caches the entries file and the
interface is responsible for maintaining the cache. Of course the
structure doesn't have to be opaque for you to do this, but being
opaque ensures that your caching mechanism cannot easily be bypassed.
the only thing i've thought of caching in the context object is
possibly the parsed config files, so we can avoid reparsing them every
time we need a config option. do people think this is worthwhile? one
issue with this is that we parse the config files in places other than
libsvn_client, so either we'd have to pass the context object down into
other libraries or we'd have to explicitly pass the config data we got
from the context object into the other libraries.
what do people think?
-garrett
---------------------------------------------------------------------
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:57 2006