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

Re: svn commit: r16652 - trunk/subversion/include

From: David James <james82_at_gmail.com>
Date: 2005-10-12 15:33:49 CEST

On 10/11/05, Daniel Rall <dlr@finemaltcoding.com> wrote:
> 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.
> 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.
Unfortunately, SWIG does not recognize anonymous structs, enums, or
unions, even if they are typedef'd. The same rule applies to our SWIG
header-wrapper generator. So, from a SWIG perspective, it's better if
we stick to our current convention of naming our datatypes.

In addition to this, I also personally find definitions easier to read
when they are named explicitly. Here's an example that shows why:
  typedef struct svn_foo_bar_t {
    ... 100 lines of member definitions ..
  } svn_foo_bar_t;

(If it weren't for the explicit "svn_foo_bar_t" at the top of the
definition, I'd have to scan through 100 lines of member definitions
to find the name of the struct.)



David James -- http://www.cs.toronto.edu/~james
Received on Wed Oct 12 23:55:40 2005

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.