[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: make-vtable

From: Ludovic Courtès
Subject: Re: make-vtable
Date: Fri, 16 Feb 2007 09:12:43 +0100
User-agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux)


Kevin Ryde <address@hidden> writes:

>> Thus, VTABLE is redundant.
> Well, except for the creation (and continued existance) of
> scm_stack_type.

Right.  But the layout that's used for VTABLE is unneeded: VTABLE only

> Yes, as long as you don't want any extra fields in the vtable (which
> is true for scm_stack_type).  I thought of that for my make-vtable
> func,
>     (define make-vtable
>       (let ((vtable-vtable #f))
>         (lambda (fields tail-size . print)
>           (or vtable-vtable
>               (set! vtable-vtable (make-vtable-vtable "" 0)))
>           (apply make-struct vtable-vtable tail-size
>                  (make-struct-layout fields)
>                  print))))
> Then wondered if it was worth bothering with.  I guess if it's used by
> stacks.c too then it should share.  (The name `struct-vtable' is taken
> by a func, but some other global name ...)

I think it'd be useful and easier to understand.  Or maybe something

  (define %root-vtable
    (make-vtable-vtable "" 0))

  (define (make-vtable layout printer)
    ;; LAYOUT must be a symbol.  We only pass a two-element init list
    ;; (corresponding to REQUIRED_VTABLE_FIELDS) because the second
    ;; field is of type `s' and gets automatically initialized.
    (make-struct %root-vtable 0 layout printer))

(And it really works!)

Both of which could (should?) be documented _before_ `make-vtable-vtable'
is even mentioned.  :-)

> I think the problem is if you want extra fields in the vtables.

Actually, one rarely needs it, just like one rarely needs to sub-class
<class>.  So it's a nice thing to have, but not something that should
make one's life harder.

> Maybe
> a third level of table descriptor could do that (as opposed to
> self-vtabling roots).

Because of the `s' field in REQUIRED_VTABLE_FIELDS, all vtables returned
by `make-vtable-vtable' are "self-vtabling".  I think it'd be clearer if
there were only one self-vtabling vtable (`%root-vtable') from which all
vtables would directly or indirectly inherit.  Thus,
REQUIRED_VTABLE_FIELDS would rather be "prprpw".

But I guess this is more of a cosmetic issue.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]