So, I'd like to see:
- s/svn_opt_revision_value/svn_opt__revision_value_t/ (we can
"publicize" it when we really need to).
- the definition be like "typedef union svn_opt... { } svn_opt...;"
Julian Foad <julianfoad@btopenworld.com> writes:
> > On Tue, 11 Oct 2005, kfogel@collab.net wrote:
> >
> >>Why is it not 'svn_opt_revision_value_t'? I thought we always used _t
> >>for types that are unaccompanied by some other type-indicating keyword
> >>(e.g., 'struct' or 'enum'). We should settle this now, since this is
> >>going into 1.3.
>
> We use "_t" consistently for structs. Most enums have no suffix, some
> have "_t", and at least one has "_e". This is our first public
> union. (Congratulations are in order :-)
>
> I favour adding a "_t" suffix.
>
> Daniel Rall wrote:
> > I too prefer the _t suffix, which is consistent with our struct naming
> > convention. While we're at it, why bother naming the enum when it's just
> > going to be typedef'd (e.g. does SWIG need that)? Leaving it anonymous
> > results in less code to read. My $0.02 USD.
>
> It is general good practice (in my world) to give every struct (and
> union etc.) a name and a typedef name that are identical: "typedef
> struct foo_t { ...} foo_t;". To declare the existence of it in order
> to have pointers to it, you need to say "struct foo_t;", and in all
> other usage it is more convenient to refer to it as just "foo_t".
>
> In Subversion we do this very consistently for structs, very
> inconsistently for enums, and there are only two unions in the public
> headers (this and another anonymous one).
>
> - Julian
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Oct 12 15:19:23 2005