A patch for libwapcaplet

Daniel Silverstone dsilvers at netsurf-browser.org
Thu Jun 18 14:33:12 BST 2009


On Thu, 2009-06-18 at 14:11 +0100, John-Mark Bell wrote:
> > I'm strongly against exposing the internals of how libwapcaplet works in
> > this manner.
> Is this exposing the internals, though?

Providing the API makes it clear that this is a *convenience only* and
that the actual value of the hash should never be relied upon to be
identical from invocation to invocation, i.e. I don't want people using
it to "identify" certain strings by their hash value, then I'd be
prepared to expose it.

> If you want to put a lwc_string into a hash table then you need to
> calculate a hash from the data. I'm not convinced that using the pointer
> to the string will produce a particularly good distribution within such
> a table.

Perhaps, however a good hash table will be using a prime number of
buckets if it can, thusly re-spreading the distribution once more,
providing the prime is large enough (e.g. 4093)

>  Therefore, the client currently has to calculate a hash itself
> from the string data. AFAICS, all this patch does is avoid the need for
> the client to calculate a hash by having lwc expose a hash value for
> each string. Whether lwc uses said hash internally is irrelevant imo.

It does tie lwc to providing the hash even if we change the internal
representation of the state at a later date (e.g. to a
prefix-sorted-tree or similar)

> Given that the most common usage of hashes in lwc clients will be sets
> or maps, they could just use a balanced tree instead of a hash.
> Thoughts?

I'm less against it than perhaps I first stated, having thought some
more about it, so providing my concern I raised first in this mail is
noted and we can come up with an appropriate set of docs, then I'd be
prepared to expose the hash, but reserve the right to deprecate that
exposure in a later version if it turns out that I can better implement
the internals of lwc some other way.

Obviously I'm not so crass as to remove the hash exposure without first
fixing any clients :-)

D.

(P.S., Bo, if you want to provide a patch for lwc, make a branch and be
sure to provide full doxygen comments including the caveat in the first
paragraph of this mail, and ensure you also provide tests and
appropriate asserts. Then tell me where the branch is and I'll review it
for merging)

-- 
Daniel Silverstone                       http://www.netsurf-browser.org/
PGP mail accepted and encouraged.            Key Id: 2BC8 4016 2068 7895





More information about the netsurf-dev mailing list