Re: hash tables: print, read, print-readably
Mike Kupfer writes:
But I still find this confusing. I would expect--both based on your
description and the documentation--that
#s(hash-table :size 29 :data ("a" "foo"))
would give me a table sized to hold 29 elements, but currently only
holding 1 element.
An XEmacs hash table sized to hold 29 actual elements has 59 buckets.
Hash tables need empty buckets to work efficiently.
> Really, the size of a hash table is
none-of-your-business-thank-you-
> very-much. ;-)
Perhaps, except I was afraid that every round-trip would result in a
larger hash table. That would eventually become my business. ;-)
It will do so if you keep fiddling the :size parameter by hand. If
you leave that alone, you'll have no problem. In fact, if the number
of actual elements shrinks enough, next time XEmacs will allocate a
smaller number of buckets.
And if it's not my business, then XEmacs probably shouldn't
expose it in
the default printed representation.
In the *default* printed representation, it's no problem. That
representation is un(read)able. ;-) In the (read)able printed
representation, it mimics the API of make-hash-table, except for the
:data key, which is basically a plist. (Currently, apparently it is
*exactly* a plist.) That seems like an excellent and self-documenting
API to me, at least for anybody who knows the make-hash-table API
already.
True, I suppose it could be abused by a merry prankster who writes
#s(hash-table :size 2147483647 :data ("a" "foo"))
or similar. But I don't recommend using this API at all, so I'm not
going to worry about it.
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta