Re: [GOOPS] make class-name a generic?

[Andreas Rottmann]

Mikael Djurfeldt <address@hidden> writes:

[ CC'ed g-wrap-dev, since Rob might be interested in that too ]

> Andreas Rottmann <address@hidden> writes:
>
>>> Could you explain why you need to add methods to class-name?
>>>
>> Because it's very convinient in my case: I'm working on G-Wrap-TNG (an
>> OO-rewrite using GOOPS of G-Wrap[0]) and in the G-Wrap environment, I
>> have "types", which can be attributed with a class name. Note that a
>> type is an instance in G-Wrap; so it would be very nice to be able to
>> say (class-name type) to get the class name associated with a type.
>
> Well, the "class-" part of "class-name" is supposed to mean that it's
> a selector for class objects.  If type is not a class object, then I
> would say it's not a good idea to use class-name on it.  Why don't you
> use the name "type-name"?
>
Because g-wrap creates GOOPS classes for the types that have a
class-name (simply put). The class-name and the type-name of a type
are not necessarily the same.

> The reason I'm putting up some resistance here is that I would only
> want to make the change if there is a real need, because this
> particular set of selectors (class-name, class-slots etc) are so
> fundamental that making them into generic functions would easily
> complicate the reflexive structure of GOOPS.  (They are a kind of
> "base cases" in the MOP if you know what I mean.)  I also have the
> feeling that they are so specific in their function that it's
> questionable if one really would like to hang new methods on them.
>
I could always try to think of another name for the accessor, but
class-name seemed the best fit.

> BTW, have you considered making your type objects real class objects?
> I'm asking without having looked at your code,
>
Well, the code is not available yet. I'll commit a sneak preview to my
archive sonish, however.

> but I remember that when I worked on a rudimentary C API for GOOPS,
> I had the idea to have classes representing "foreign" objects,
> i.e. objects not allocated or administered by GOOPS.  That way one
> could perhaps more easily use some of the facilities in GOOPS such
> as slot access and accessors.
>
The type objects I talk about are not runtime objects, but
wrapper-generation-time objects, used to describe the type for the
wrapper generator, which then spits out the C code that ends up
implementing the type (conversion C<->Guile, C value destruction,
...). I have a <gw-type> class with several associated generics which
are responsible for creating the code, which then are specialized for
various specific types, e.g. there is a <simple-type>, which allows to
for simple forms to be used for wrapping/unwrapping. <simple-type>s
are used for e.g. integers, booleans and other values with an
immediate representation in Scheme:

(define-class <simple-type> (<gw-ffi-type>)
  (type-check #:init-keyword #:type-check)
  (wrap #:init-keyword #:wrap)
  (unwrap #:init-keyword #:unwrap))

[...]

(add-type! wrapset 'float
           (make <simple-type>
             #:c-type-name "float"
             #:type-check '("SCM_NFALSEP(scm_number_p(" scm-var "))\n")
             #:unwrap '(c-var "= scm_num2float(" scm-var ", 1,"
                              " \"gw:scm->float\");\n")
             #:wrap '(scm-var "= scm_float2num(" c-var ");\n")
             #:ffspec 'float))

The code currently does not create classes itself, but the class-name
is supposed to refer to a class generated "from outside". The
class-name feature is used by the guile-gobject bindings to create
methods specialized to the classes created by guile-gobject (which has
a built-in facility to create a GOOPS class for a GObject class). So
it would make sense to add #:class-name '<real> in the above make
invocation.

Hope that clears it up a bit.

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

Say NO to Software Patents! -- http://petition.eurolinux.org/