Re: hash tables: print, read, print-readably
Stephen J. Turnbull wrote:
Mike Kupfer writes:
> So it's punching a hole in the hash table abstraction and exposing
> an implementation detail.
So what? It prints an object ID, too, which is also internal. The
usage ratio is a useful number to know in some cases (it has a bearing
on the performance of hash tables) and easy enough to print.
Well, we could have a discussion about when internal information should
be displayed, but for now I'd be happy if we change the keyword.
> To make matters worse, the printed representation uses the same
"size"
> keyword. So "size" means one thing in the default printed
> representation, but it means something else in the readable
> representation and in the API.
It actually means different things in the readable representation and
in `make-hash-table' it seems to me. In the readable representation,
it's the current number of items, while in the API it's the expected
long-run number.
Yeah, I thought it a little odd when I first noticed that. But I
convinced myself that for a literal constant, the current number of
items is the same as the expected long-run number. ;-)
The thing is, for make-hash-table and the readable representation, the
number refers to objects, not buckets.
But if you find a better word for the size in the unreadable
representation, we can use it there. I don't much like either of
"usage" or "ratio", and "usage ratio" is too long. It
should be
short, too, no more than about 5-6 characters.
I was thinking either "buckets" or "slots". Would either of those
work
for you? I lean towards "buckets", as "hash bucket" is, I think, a
well-known idiom, but either would do.
> The docstring for print and friends should mention
print-readably. A
> specific list of objects for which print-readably is relevant (e.g.,
> hash table) would be nice, but I can see arguments for not including
> such a list.
The docstring for print-readably already has such a list, but it's
only two types long, specifically missing hash tables. I think that
is where it belongs.
Okay.
mike
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta