Re: New smob interface

[Jim Blandy <jimb@red-bean.com>]

> I'd like the naive user to be able to use a simple function.  If he
> starts to use a mark function of his own design he anyway has to do a
> lot of reading.  Therefore I don't see any big danger here.  We'll
> just put a few big NOTEs at suiatble locations in the manual (like at
> the scm_set_smob_mark function).

It seems to me that the right place to explain restrictions on the use
of scm_make_smob is in the documentation for scm_make_smob itself.  :)


I like the idea of allocating a smob type and then plugging in the
functions you want.  It makes it possible to extend the smob concept
without going and editing every smob structure in the sources (and
the users' sources!).  That's an improvement.

Smob names are a good thing, too.  Beyond making a meaningful default
print function possible and helping GOOPS, I think it will help GDB's
Guile support.  I'm thinking about reimplementing GDB's support for
Guile so that it doesn't rely on the interpreter being sane (you need
the debugger most desperately when it isn't!), and having the name in
the smob structure makes my life easier there, too.


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.

("Great, Jim, so where were you when I asked you for advice two months
ago?"  Mea maxima culpa.)