Re: [Fwd: Re: First look at new g-wrap -- it's slow!]

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> When this procedure is called, it will store information about the
> return type (henceforth `R') as (make mchars #:options '(caller-owned)).
> Consider the (proposed) hierarchy of R:
>          <gw-type>
>              |
> mchars - <gw-value>
>    |
>    R
>
> meaning <gw-type> is the metaclass of <gw-value>, and <gw-value> is the
> direct super of mchars. Later, when you go to make the code, you will
> have to (slot-set! R 'var ...) and also for 'wrapped-var.
>
> Then to generate the code that takes the c value and makes the scm
> value, you just have to call (wrap-value-cg R status-var). The type is
> implicit in the R's hierarchy; specifically, R is an instance of mchars.
>
I think I found a little quirk in the approach: I currently have
methods on types likes this:

(define-method (global-declarations-cg (wrapset <gw-wrapset>)
                                       (mchars <gw-ctype-mchars>))
  (list (next-method)
        "#include <string.h>\n"))

This would not work anymore when a "type" is in fact a class. You'd
have to specialize on the metaclass of <gw-mchars>, which would be
<gw-type>, unless you defined a specific metaclass for <gw-mchars>;
this means you have to add a metaclass to every type that needs this
kind of per-wrapset methods.

Andy
-- 
Andreas Rottmann         | address@hidden      | address@hidden | address@hidden
http://yi.org/rotty      | GnuPG Key: http://yi.org/rotty/gpg.asc
Fingerprint              | DFB4 4EB4 78A4 5EEE 6219  F228 F92F CFC5 01FD 5B62

A. Because it breaks the logical sequence of discussion
Q. Why is top posting bad?