Re: new `obarray` type

[Stefan Monnier]

>> The patch below introduces a new type for obarrays, distinct
>> from vectors.  Among other things, this makes it possible to print them
>> in a more useful way (it doesn't print the contents, only the size, so
>> the printed form is not computer-readable, but it's more
>> palatable to the user).
>> Printing obarrays in a `read`able way seems like something that should
>> be under the control of variable, since it's unclear in general what it
>> would mean (for abbrev-tables, it would probably mean to print the name
>> of every symbol, along with it value, function, and plist slots, but
>> doing that for the `obarray` variable doesn't seem right (and it's not
>> even clear what the `value` of each symbol in it should be, for
>> buffer-local symbols)).
> Let me be the devil's advocate: are there any clients of this change
> other than abbrev-tables defined during the build time?

Actually, this change doesn't even solve the problem of dumping&reloading
abbrev-tables.  I think we'd be better off reimplementing abbrev tables
using something like hash-tables.

IOW, while this new obarray type was inspired by the work on dumping
Emacs, it doesn't really attempt to solve that problem.  All this does,
really, instead is to provide a separate type so that cl-defmethod can
dispatch on it, and so we can print it in a human-readable way and using
the usual #<...> notation that makes it clear that the output is not
`read`able.

> Because if they are the only justification, then it's much easier to
> define them in startup.el instead, which will make the problem go
> away.  Right?

Definitely.


        Stefan