Re: modules anyone?
On Thu, Mar 16, 2000 at 02:53:10PM -0800, Martin Buchholz wrote:
I just noticed that Olivier got rid of last_lrecord_type_assigned (a
C
variable), and replaced it with lrecord_type_count (a C compile-time
constant). Olivier, this was not my intent with the changes to use
compile-time constants for lisp object type identification.
I know but...
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.
...it for now simply doesn't work. You can't use
DECLARE_LRECORD*/INIT_LRECORD* in a module to define a new type since
you (rigthfully) killed the dynamicity in type number allocation. I
didn't want to leave something that not so obviously didn't work. I
don't want modules to know about last_lrecord_type_assigned or the
lrecord_implementation array.
What I especially want to avoid is somebody defining a new set of
types with constant numbers starting at lrecord_type_count, which
would break horribly as soon as two modules are loaded simultaneously.
I leave the choice to Olivier.
I'd rather not put it back and leave the rest in the broken state it
was in. Whoever wants to define new types in modules, tell me the
kind of interface you'd like to have and I'll implement it (and ensure
that the dumper deals with it). Remember that we somehow need the
DEFINE/DECLARE/INIT trilogy.
OG.