Re: New smob interface

[Ken Raeburn <raeburn@raeburn.org>]

It looks good, but you lost me here:
 
> IMPORTANT NOTE: If the advanced user chooses to store GC:d data in his
> malloced block and writes his own mark function, it is no longer
> possible to use scm_make_smob!

After some thought, I came to the conclusion that you were referring
to the ordering of initialization of the fields versus creating the
SCM object(s), and how GC before all the fields get initialized would
be bad.  If so, that should probably be mentioned in documentation on
the New Way.  Probably with a reminder that new GC systems are being
experimented with, so even though we don't have concurrent GC now, and
GC might not be run during the object's initialization, we might get
concurrent GC later, and that could break the user's code.

Maybe scm_make_smob(my_type) should be SCM_NEWSMOB_SIMPLE(z,my_type)
so that it looks similar to SCM_NEWSMOB, except that it doesn't need
the pointer to the already-filled-in structure.  (It could of course
be a macro expanding to a call to a scm_make_simple_smob or
scm_make_uninitialized_smob function.  But I think the name
"scm_make_smob" carries no implication that it's *not* safe for
non-trivial objects.)  Either that, or SCM_NEWSMOB should return a
value and not assign to an lvalue.

Just MHO...

Ken