Re: guile-gnome changes

[Andreas Rottmann]

Andy Wingo <address@hidden> writes:

> On Wed, 2004-02-11 at 20:06, Andreas Rottmann wrote:
>> > * Documentation for guile-gnome is now done in texinfo. I haven't tried 
>> >   making info files yet, I just use a script to make the docs in
>> >   http://ambient.2y.net/tmp/guile-gnome/docs/tutorial/. Info sucks ;)
>> >
>> Well, I like it, since it nicely integrates into Emacs ;-)
>
> I'll see about getting this together. Automake should make it easy.
>
> I do think, however, that programs should install their texinfo files.
> Computers are fast enough these days to deal directly with texinfo, not
> crappy substitutes (info :).
>
Well, using elisp for dealing with texinfo directly may be slow
anyway ;-).

>> > Interpreted languages don't need types and classes; the classes are the
>> > types. This realization could lead to a rethinking of our confused
>> > primitives/nonprimitives distinction. Dunno, though.
>> >
>> Yes, I always wondered what is so primitive about our primitives
>
> Dunno. It's a holdover from 0.2.0. It does indeed need rethinking.
>
> To me, the logical distinction is not primitives/goops, it's more along
> the lines of functionality. If you look at the header for gtype.h, it
> says:
>
> /* GObject - GLib Type, Object, Parameter and Signal Library */
>
> My categories would be:
>
> Things to hide from a typical session:
> 1) GType -- the base type system, only dealing with GTypes
> 2) Typed values: GValue, to and from scheme
>
> Things to export:
> 1) GObject: its signals, properties, ancestry, etc. But never really
> dealing in GTypes, except maybe for gtype-instance->type. Maybe.
> 2) Parameters: Necessary for deriving new types with properties. Also
> necessary for introspecting properties.
> 3) Closures
> 4) Enums and flags: genum->symbol, gflags->value-list, etc.
>
> All of these are essentially separate modules. There are some points
> where they touch (parameters and signals touch values, for instance, and
> a GObject can be stored in a GValue), but it might be good to separate
> them into (gnome gobject value) and (gnome gobject type) or something.
> Don't know! Also, you might need a separate module to set up the GOOPS
> class hierarchy. Parts specific to, say, GObject can be implemented in
> the GObject file itself.
>
> Well, that's enough blathering for one email. What do you think? Do we
> care? I would like to think that this is our last major reshuffle,
> besides maybe module locations.
>
I basically agree to the above (especially not to export the GType
stuff to the Scheme level). I don't care too much, however.

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

Beware of bugs in the above code; I have only proved it correct,
not tried it.  -- Donald E. Knuth