Re: guile-gnome changes

[Andy Wingo]

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 :).

> > 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.
-- 
Andy Wingo <address@hidden>