Hi!
Kevin Ryde <[EMAIL PROTECTED]> 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
needs REQUIRED_VTABLE_FIELDS.
> 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
like:
(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.
Thanks,
Ludo'.
_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-devel
