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

[Michael Livshin]

Dirk Herrmann <address@hidden> writes:

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

OK.  my claim, basically, is this: most user smobs are fixed-size
(don't ask me for references, it's a wild guess).  so this is the
usage pattern the smob API should be optimized for.

you are right that there are also cases where smobs are
variable-sized, and so we do need the GC bookkeeping stuff after all,
too.  but it should be regarded as "advanced".  an extension writer
who just needs to wrap some of his C stucts in smobs shouldn't have to
deal with it.

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

what's confusing about it?

-- 
Everyone's raving about post-porn, but I think it sucks. It's just
naked people getting dressed.
                              -- *Legion* in rec.music.progressive