>>>> "AB" == Andrew Begel
AB> Ok, here's the next part. My dynamic module needs to define new LRECORD
AB> types. In XEmacs 21.2, someone went and changed how this works so that I
AB> have to go into the XEmacs source code (lrecord.h) and modify an enum
AB> (lrecord_type) to add my types in there. That's lame, and certainly not what
AB> I was expecting when writing a dynamic module (that XEmacs shouldn't be
AB> required to know about it when i compile Xemacs).
AB> In addition, the docs should be updated to note that not only do you have to
AB> DECLARE_LRECORD and DEFINE_LRECORD_IMPLEMENTATION, but you also have to now
AB> init your new types in syms_of_<module> by INIT_LRECORD_IMPLEMENTATION
AB> before you call any DEFSUBR's.
I was not aware of a module that defined a new lisp object type. I'm
The intention was for the modules to be able to define new lisp object
types, but in view of the lack of an existing such external module,
this capability still needs to be completely implemented. The idea
was that lrecord.h only contains a list of the *predefined* lisp
object types, and a module that adds new lisp object types extends the
list and increments the count of lisp object types used in alloc.c and
dump.c. Also, there is some implementation inconsistency, since both
I and Olivier Galibert have hacked this code.
AB> Whoever owns the lrecord.h type stuff, will this be changed to enable
AB> dynamic modules to declare new LRECORD types?
That's the intention. You could provide a patch.
Non-built-in lisp object types will have a slight performance penalty.
Builtin object types (i.e. those defined in lrecord.h) can have a
slightly more efficient FOOP macro, since the lrecord_type index can
be compared to a compile-time constant, while types defined at runtime
need to be compared to a runtime constant. As a result, non-built-in
lisp object types need a slightly different API - the current
DEFINE_LRECORD_IMPLEMENTATION and INIT_LRECORD_IMPLEMENTATION won't
work without hacking, and perhaps can't be made to work without a
performance penalty on all existing code.
Would you like to work on this?
For your purposes, it might be easier to modify lrecord.h, depending
on where your module is to be used.