guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

What do people think about g-wrap going in to a CVS module?


From: Rob Browning
Subject: What do people think about g-wrap going in to a CVS module?
Date: 13 May 2001 18:04:07 -0500
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7

I'm finally writing up some documentation for g-wrap, and am planning
a release to conincide with our upcoming gnucash 1.6.0 release (having
two projects I work on with version numbers in such close parallel
right now is kinda confusing -- I keep forgetting to specify what I
mean when I say "the 1.6.0 release" depending on the audience).

Anyhow, I was wondering if adding g-wrap as a top-level CVS module
would be a good idea.  I don't really know if anyone else would have
interest in hacking on it (it's a *mess*, but it does work).

FWIW.  I just stuck a nice "Caveats" section into the introduction.

@node Caveats, Overview, Introduction, Introduction
@section Caveats

@enumerate

@item
I'd like to state right up front that g-wrap is to some extent an
experimental work.  It seems useful, but it is certainly not elegant, at
least not yet, and maybe not ever, and it's somehat hard for me to say
whether that's a statement about the problem, or the current solution.

@item
The current implementation of the wrapper types (normal, non-native, and
enumerations), and the whole "hash-table" oriented infrastructure behind
them should almost certainly be re-written reasonably soon to use goops
instead of the ad-hock mess that's there right now which somewhat fakes
a mini-inheritance structure.  None of this has any effect on wrapper
run-time, but it's ugly.

@item
G-wrap should be made smarter about guile modules.  In particular it
needs to be migrated away from the old (and deprecated) way of
implementing use-modules completely in one .so file.  Making this
change will involve switching g-wrap to generate a .scm file *and* a
.so.  Once that's done, perhaps we should allow for the specification
of scheme code that should be inserted into places in the parent .scm
file (This might eliminate the need for many uses of the
gw:inline-scheme function, or perhaps better yet, we should figure out
a way to orient g-wrap much more closely toward generating *just* the
C wrappers and let the user create the top-level .scm file themselves.
I'm not sure that would retain all the flexibility, but it would
simplify things, and I already worry that g-wrap is suffering from
mission-creep.

@item
All of these things are my (rlb's) fault, not Christopher's :>

@end enumerate

-- 
Rob Browning <address@hidden> PGP=E80E0D04F521A094 532B97F5D64E3930



reply via email to

[Prev in Thread] Current Thread [Next in Thread]