Re: should GOOPS be built-in?

[forcer <forcer at mindless dot com>]

Marius Vollmer <mvo@zagadka.ping.de> writes:

> Michael Vanier <mvanier@bbb.caltech.edu> writes:
> 
> > Since we're all in soul-searching mode and pondering the future of
> > guile, I thought it would be a good idea to bring up the issue of
> > whether GOOPS should be built-in to the core of guile or not.
> > Personally (and I haven't thought this through in detail, this is
> > just my gut feeling), I tend to think that it shouldn't be, but
> > should rather be a module.
> 
> I don't agree.  Having support for the OO style of programming is just
> too useful to not use it in the core itself.

Just to add my humble opinion...  My general idea is that the
guile core should be exactly that - the "core" - and thus be as
small (and clean, and extensible) as possible. The problem is
that Guile isn't "just" a Scheme interpreter, but also an
extension library. And C programs surely want to add objects to
the Scheme world.

I don't think it would be bad to leave GOOPS out of the core
(distribute it as a "standard" module with posix and similars),
but make it possible for the C world to add objects just like
smobs. This includes a simple way of using GOOPS from a C program
- e.g. just #define GUILE_USE_GOOPS or so and add objects. Just
being able to load GOOPS from the C world (e.g. gh_use_goops();)
doesn't solve the problem since linking wouldn't be easy if GOOPS
has to be linked after the program start.

A few people mentioned using GOOPS in the Guile core itself. I
head a few controversal opinions about this. Let's see how it
develops, if we use GOOPS in the core, it wouldn't be *too*
intelligent to have it as a module. If we don't use it in the
core, it wouldn't be *too* intelligent not to have it as module.

Time will tell.
	- forcer

-- 
((email . "forcer@mindless.com")       (www . "http://forcix.cx/")
 (irc   . "forcer@#StarWars (IRCnet)") (gpg . "/other/forcer.gpg"))