This is the mail archive of the
guile@cygnus.com
mailing list for the Guile project.
Re: New smob interface
- To: Jim Blandy <jimb@red-bean.com>
- Subject: Re: New smob interface
- From: Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>
- Date: 20 Jun 1999 01:04:24 +0200
- Cc: guile@cygnus.com
- References: <199905231749.TAA09627@mdj.nada.kth.se> <tx1wvxz8m4k.fsf@raeburn.org> <xy7yaifbawy.fsf@mdj.nada.kth.se> <m3ogic53u6.fsf@savonarola.red-bean.com>
Jim Blandy <jimb@red-bean.com> writes:
> I'm not sure that this `naive developer' interface is where we want to
> go, though. scm_make_smob is so restricted --- it can't contain
> pointers or SCM objects, or anything which needs to be explicitly
> deallocated, like file descriptors --- that I'm tempted to say that
> one should be using vectors or pairs or uniform arrays instead. The
> only things you can put there are numbers and characters.
>
> The developers which I think are more important to serve are people
> like Klaus, who are trying to interface Guile with an external library
> with its own vocabulary of abstract types. I think his situation with
> the ncurses interface is pretty typical --- if we can help him, we've
> helped the broadest class of users. But the "naive" smob interface is
> useless to him.
>
> If we do provide "naive user" functions, then they should be a layer
> on top of the fully general functions. That's not true of your system
> --- scm_new_smob's second argument is only useful for trivial smob
> types.
Yes, probably the kind of function most developers would use should be
on the gh level, not the scm level---the primary purpose of which is
to implement Guile itself.
When you're talking about scm_new_smob I suppose you're referring to
scm_make_smob_type which takes the struct size as it's second
argument. I like this function. It will minimize the amount of code
needed to implement most of Guile's internal smobs.
But I agree that the idea of the "naive interface", which really only
is the function scm_make_smob is a bit misplaced since the naive user
would prefer to use the gh interface, and since its use is very
limited as you point out.
This means crap scm_make_smob, but keep scm_make_smob_type and
SCM_NEWSMOB. Right?
(Actually, what we really would need is some kind of records a la Mike
Livshin---a system which makes it easy to "box" application data
structures. Such a system could hopefully also replace the current
structs.)
(BTW, I'm experimenting with a C interface to Goops. I'll put it into
Goops before release so that people can try it out and crap it or
improve it.)