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

Re: [PATCH] Re: The new svn_wc_adm_*_depth functions.

From: <kfogel_at_collab.net>
Date: 2004-03-12 17:35:18 CET

Benjamin Pflugmann <benjamin-svn-dev@pflugmann.de> writes:
> When reading source code which you are unfamiliar with, functions
> named dothis(), dothis2(), dothis3() are one of the worst things,
> IMHO.

I think this "2" (or "N") suffix is actually something of a
convention. I've seen it before in more than one place, and never
been confused about what it meant: an API needed variants. Consider
popen(), popen2(), popen3().

It's hard to say in absolute terms "It's confusing" or "It's not
confusing". All I can tell you is that I've not been confused by it,
and other APIs have chosen a similar course.
 
> There is no indication of what the "2" means except that is some kind
> of variation of the theme of dothis(). What then happens is that
> everytime one sees dothis() or dothis2(), one has to get back to the
> doc/definition to see which of them did what, because there is usually
> no easy way to build a "memory hook" out of an enumeration.
>
> I'd prefer any of
> - foo_pool()
> - foo_recommended()
> - foo_for_api_3_0()
>
> ...or whatever makes more sense to you. But please don't simply
> enumerate them. Pretty please?

I can put a note in HACKING about what '@deprecated' means -- i.e,
that it's the *API* that's deprecated, not necessarily the name. We
should simply assume an arbitrary amount of API change when 2.0 comes
out. It's not like it'll be that hard for anyone to fix their apps.
You try to compile your code, it doesn't work, you go do the obvious
thing (removing the "N" suffixes from functions, basically).

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 18:42:48 2004

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.