Re: new `obarray` type

["Herring, Davis" <herring@lanl.gov>]

> Indeed, why not just print _all_ vectors by printing only their size?
> The arguments which apply to obarrays surely apply equally to all
> vectors.

No -- obarrays are special in that they have hash buckets chained with invisible link pointers.  It is a disservice to the user to have this appear as a normal vector.  (A minor one, though, since most users never look at it at all and some of the rest know the lie.)

> Not rarely, particularly in CC Mode, I will be dealing with obarrays
> with relatively small numbers of symbols.  Of course I want to see these
> symbols' names when I ask for that obarray to be printed.

And if it happens that your symbols suffer a hash collision?  How long will you spend wondering where your Nth expected symbol went?

> I suspect most obarrays in existence (with the essential exception of
> Emacs's main obarray) are relatively small, hence printing them as a
> vector is the Right Thing to do.

I don't think printing an arbitrary subset (dependent on the order of insertion) of the contents of an obarray can be considered the Right Thing.

> Would a new obarray type prevent any vector operations being carried
> out on it, should any package do such things?  If so, that would be a
> Bad Thing.

The Elisp Reference Manual says specifically not to try to edit an obarray (but to use [un]intern); what else would you call -- length (which counts buckets)?  aref (which, given a meaningless index, fetches the same random subset of symbols that would be printed)?

Davis