Re: Do we trust the man on the GC trigger?

[Dirk Herrmann]

On 28 Aug 2001, Michael Livshin wrote:

> let's try a little thought experiment.  let's pretend that smob's size
> is part of the type, so there's no need for a user (or a Guile
> developer, for that matter) to manually allocate and deallocate smob
> data (in fact, I believe it's already the case: see `scm_make_smob').

I disagree:  We should not assume that each smob has an associated fixed
size with it.  It is an unnecessary restriction and would inhibit users
from providing home brewn vector types, auto resizing hash-tables
etc.  One could argue that either all these should be implemented using
goops, or that one day guile will provide all those features you could
probably think of anyway.  However, we are not that far:  goops does not
have a C interface yet, and guile does not yet provide all the features
you could think of :-)

I'd rather vote for the opposite direction:  Getting rid of scm_make_smob.  
As (in my opinion) we need to leave the possibility to do the memory
management to the user (as I've explained above), it is confusing to
also have scm_make_smob as a second mechanism.

> I say we should clean up our own usage of the bookkeeping functions
> (not _such_ a lot to fix) and simply stop exporting them.

Functions like scm_malloc (as suggested by Marius) _need_ to be exported
in order to allow guile-aware code to avoid 'out-of-memory' errors if
there's enough memory free-able by the gc.

Best regards,
Dirk Herrmann