Re: New smob interface

[Mikael Djurfeldt <mdj@mdj-pc.nada.kth.se>]

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