Re: modules anyone?

>> The idea was that future code in a module could define a new lrecord >> type dynamically, and increment last_lrecord_type_assigned. So it >> actually makes sense for last_lrecord_type_assigned to be initialized >> to lrecord_type_count and never subsequently modified in any code >> shipped with XEmacs, and for various bits of code to use >> last_lrecord_type_assigned instead of lrecord_type_count. Of course, >> it doesn't make sense for modules to be loaded before being dumped, so >> the dumper could use either symbol. However, it seems cleaner to use >> last_lrecord_type_assigned. I suggest you resurrect >> last_lrecord_type_assigned. OG> ...it for now simply doesn't work. You can't use OG> DECLARE_LRECORD*/INIT_LRECORD* in a module to define a new type since OG> you (rigthfully) killed the dynamicity in type number allocation. I OG> didn't want to leave something that not so obviously didn't work. I OG> don't want modules to know about last_lrecord_type_assigned or the OG> lrecord_implementation array. It's true that DECLARE_LRECORD*/INIT_LRECORD* would have to have dynamic versions manipulating last_lrecord_type_assigned (like the old code) to be used in a module. Such macros are not written yet, although writing them would be relatively straightforward. And the need may never arise - the existing lisp object types are sufficient for implementing any real-world functionality.