On Thu 2004-03-11 at 22:42:51 -0700, D.J. Heap wrote:
> kfogel@collab.net wrote:
> [snip]
> >
> >If we're going to fall back to the old names, then the "2" variants
> >might make the most sense.
> >
> >IMHO, we should do this. By resetting our APIs back to the
> >names-of-first-choice, we avoid names growing arbitrarily long (think
> >3.0).
> >
> >Thoughts?
>
> It looks like an agreement is forming on the '2' variants (it sounds
> reasonable to me) -- if there are no objections then I will wait another
> day or so and update the patch to rename the functions with that scheme
> and submit it for review?
May I humbly ask that you reconsider giving the function get an at
least somewhat meaningful name?
When reading source code which you are unfamiliar with, functions
named dothis(), dothis2(), dothis3() are one of the worst things,
IMHO.
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?
Bye,
Benjamin.
PS: If these go into 1.1.0 or the like, which is my current
understanding, we have to live with the name until 2.0, correct?
If not, ignore my plea. But if so, what if we need another change
after 1.1.0 is out with dothis2()? We get a dothis3() in 1.3.0 and
a dothis4() in 1.9.0? Ok, ok, I exagerate, but you get the idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Mar 12 16:42:50 2004