[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Hide internal data in svn_wc_entry_t struct

From: Ivan Zhakov <chemodax_at_gmail.com>
Date: 2006-12-28 13:18:01 CET

On 12/28/06, Malcolm Rowe <malcolm-svn-dev@farside.org.uk> wrote:
> On Thu, Dec 28, 2006 at 02:24:18PM +0530, Madan U S wrote:
> > > Do you mean use name "baton" or use baton syntax with "void *"?
> >
> > Both.
> >
> > void, because, introducing svn_wc_entry_private_t still leaves space for ABI revving, when we have svn_wc_entry_private2_t.
> >
> > the word 'baton' because this would mean wc specific baton containing wc specific information... and the term is pretty well-known in svn-dev-land.
> >
> Batons are usually provided by the caller, not the library. They're
> handed back to a callback, hence the name. An existing example of
> private data would be within the FS layer, within an svn_fs_t, where we
> just call it 'fsap_data'.
> From the caller's point of view, I don't believe there's any difference
> between a 'void *' and a pointer-to-opaque type, since all pointers are
> the same size (and you'll never be able to dereference either); we'd
> therefore never need to create a svn_wc_entry_private2_t.
Oh, sorry. Of course we should use pointer to svn_wc_entry_private_t.

> That said, we don't need the type publically named for any other reason,
> so just creating a 'void *private; /* private data for libsvn_wc */'
> field would make sense to me.
I prefer use pointer to published structure because we can use it with
type cast. Just write: entry->private->keep_local = TRUE;

If we'll use void *, we have to cast it like this:
((svn_wc_entry_private*)entry->private)->keep_local = TRUE;
Which is ugly for me.

Ivan Zhakov
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Dec 28 13:18:09 2006

This is an archived mail posted to the Subversion Dev mailing list.