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

Re: Keywords as hash: API design: null or empty hash

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-09-22 14:42:14 CEST

Julian Foad wrote:
> John Peacock wrote:
>> Julian Foad wrote:
>>> The problem is that the keywords-as-hash API is inconsistent in how it
>>> represents "no keywords": svn_subst_build_keywords2() generates an empty
>>> hash, but all of the other functions expect NULL (but don't require it).
>>>
>>> I agonised over this all afternoon, wondering if the keywords-as-hash
>>> API is acceptable, and researched the existing use of apr_hash_t in
>>> our APIs, finding that we hardly ever provide or accept NULL.
>>> However, the existing use of keywords did use NULL (for
>>> svn_subst_keywords_t *), so I decided the API is OK as it is.
>>
>> An additional argument in favor of accepting NULL instead of an empty
>> hash is that it is much easier to hard code NULL in internal calls where
>> the keywords are not important/needed.
>>
>> Although we are moving to cut 1.3 on Friday, it still isn't too late to
>> change svn_subst_build_keywords2() to return NULL instead of an empty
>> hash, thus making the usage more consistent.
>
> Mmm. I'm inclined to leave it as it is. Changing it in that way would
> add
> one sort of consistency, but remove another sort: none of our other
> functions for any kind of data can return null instead of an empty hash.
> And while it would make testing for emptiness easier, it would make other
> operations (such as looking for a specific keyword in it) harder.
>
> What the keywords-as-hash API does now is to be conservative in what it
> gives out, and forgiving in what it accepts. That's not the only right
> way
> to design an API but it's one way of explaining the apparent mismatch as a
> good thing.

Was there any different significance between an allocated
svn_subst_keywords_t filled with NULL values, and a NULL
svn_subst_keywords_t * pointer?

I thought there might have been, but it is a long time since I touched that
code.

Max.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 22 14:43:08 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.