Re: smobs

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Dirk Herrmann <dirk@ida.ing.tu-bs.de> writes:

> Unfortunately, this can not be solved by simply providing a set of macros
> for smobs with raw data and smobs with SCM values:  Since multi cells are
> introduced there are too many possible combinations for this to make
> sense.
> 
> We could (perhaps) use some kind of macro magic, like:
> 
> SCM_NEW_SMOB_3 (type, WORD, x, OBJECT, y, WORD, z)
> 
> which constructs the appropriate macros SCM_SET_CELL_WORD_1,
> SCM_SET_CELL_OBJECT_2 and SCM_SET_CELL_WORD_3 based on the type tokens
> given together with each date.
> 
> Currently, I can't think of a better solution.  Maybe anybody else can?

I think we should treat these values as raw data (which is the most
general form of data) and let it be up to the programmer to do the
correct type conversions.

> Another thing:  The term smob is somehow part of guile's history, but
> since we are brainstorming about API issues anyway, wouldn't it make sense
> to find some better name for it?  small objects - it's not really
> appropriate.  If the smob interface will be changed, it would again be the
> right time to think of something better.  (We can, as always, try to keep
> things backwards compatible for some time.)

This is a part of Guile which may change in the near future.  Note
that the recent introduction of 4-word cells enables some
reorganization in the type system.  Also, when the structs are
replaced and GOOPS is merged we have further possibilities.  We might
even be able to simplify things down to one single object
representation.

In this respect, it doesn't make sense to make changes now, before we
have the complete picture.