On Mon, Apr 29, 2002 at 09:42:46PM +0100, Piers Cawley wrote: > Steve Fink <[EMAIL PROTECTED]> writes: > > > On Mon, Apr 29, 2002 at 01:41:56PM -0400, Mike Lambert wrote: > >> - Make an array of buffer data, in order of insertion into the hashtable. > >> set pmc_pointer and buffer_ptr and let the GC rip through it. > >> - The hashtable itself just uses indices into this array. Each > >> linked-list node would be a PMC header, that follows the logic mentioned > >> above, where the linked-list node data would simply be an integer lookup > >> into the array of buffer data. > > > > A bucket needs at least: > > - key : STRING* > > Um... Larry's already said that you're going to be able to use > arbitrary objects as keys. Just to make life even easier for > everyone :)
Yeah, I know. I'm ignoring that for now, because there are a dozen different things that could mean. The semantics aren't defined yet, and I think parrot needs hashes sooner than would be possible if we waited for the discussion of semantics to settle on something. So my stance is that hashes with only STRING keys will always be needed anyway, because hashes are used in many performance-critical places and you can't afford the speed and space hit of using generalized hashes. It's even possible that Perl6 hashes will have STRING hashes underlying them, but it really depends on the exact semantics for whether that makes any sense. And I bet a lot of languages will be perfectly happy with STRING hashes. (And a STRING can be any wad of binary data.) Way back when, I even wrote RFC266, which gives a brief proposal of one set of semantics, and talks about alternatives. So I'm definitely in favor of fancier hashes, but not until the details have been hammered out.
