Re: modules anyone?
>>>> "OG" == Olivier Galibert
<galibert(a)pobox.com> writes:
OG> 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.
OG> 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.
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.
OG> What I especially want to avoid is somebody defining a new set of
OG> types with constant numbers starting at lrecord_type_count, which
OG> would break horribly as soon as two modules are loaded simultaneously.
> I leave the choice to Olivier.
OG> I'd rather not put it back and leave the rest in the broken state it
OG> was in. Whoever wants to define new types in modules, tell me the
OG> kind of interface you'd like to have and I'll implement it (and ensure
OG> that the dumper deals with it). Remember that we somehow need the
OG> DEFINE/DECLARE/INIT trilogy.
Olivier: Now that I understand your motivation, I am content with the
status quo. On to finishing 21.2.
Martin