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

Re: svn commit: rev 3151 - clients/rapidsvn/trunk/src/tests/svncpp clients/rapidsvn/trunk/src/svncpp

From: Brent R. Matzelle <bmatzelle_at_yahoo.com>
Date: 2002-09-10 20:04:50 CEST

--- Ben Collins-Sussman <sussman@collab.net> wrote:
> "Brent R. Matzelle" <bmatzelle@yahoo.com> writes:
>
> > --- Philip Martin <philip@codematters.co.uk> wrote:
> > > "Brent R. Matzelle" <bmatzelle@yahoo.com> writes:
> > >
> > > > > Isn't 'export' a keyword? How is that you can get away
> naming
> > > a
> > > > > function 'export'?
> > > > >
> > > >
> > > > It isn't with with MSVC++ 6. Are you using gcc?
> > >
> > > export is a keyword in standard ISO C++ and should not be used
> as a
> > > name. Comeau's EDG-based 4.3 compiler is the only compiler I
> know
> > > of
> > > that supports export.
> >
> > Okay, since it is a keyword does anyone have any suggestions for
> an
> > alternative name? How about 'extract()', 'send()', or
> 'transport()'?
> >
> >
> > One other thing. 'switch' is a reserved word so i named the
> wrapper
> > method Modify::mirror() for svn_client_switch(). Does anyone
> have an
> > issue with that?
>
> It seems silly to start inventing aliases for subversion client
> routines. Nobody wants to remember that 'mirror' means switch, or
> that 'extract' means export.
>
> Why don't you just namespace-protect the object methods with svn
> prefixes? That's our standard practice throughout our C code.
>
> foo::svn_switch()
> foo::svn_export()
> etc.

That defeats the purpose of the C++ namespacing. Double namespacing
doesn't look any better than aliasing:

svn::svn_switch() as compared to svn::mirror()

Does the C API have to use these C++ reserved words?

Brent.

__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 10 20:05:27 2002

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.