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
