[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [GOOPS] make class-name a generic?
Re: [GOOPS] make class-name a generic?
Tue, 24 Feb 2004 16:43:01 +0100
Gnus/5.1006 (Gnus v5.10.6) Emacs/21.3 (gnu/linux)
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) 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
#:type-check '("SCM_NFALSEP(scm_number_p(" scm-var "))\n")
#:unwrap '(c-var "= scm_num2float(" scm-var ", 1,"
#:wrap '(scm-var "= scm_float2num(" c-var ");\n")
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
Hope that clears it up a bit.
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/