Re: Name of smob type, new field in scm_smobfuns?

[Greg Harvey <Greg.Harvey@thezone.net>]

Mikael Djurfeldt <mdj@nada.kth.se> writes:

> I'm currently adding support for smob types to Goops and discovered
> that I have a problem finding good names for the smob classes.
> 
> E.g., I'd like the class of guardians to be called <guardian>, but
> there is no way for the smob class creation function to know that
> since smobs are nameless.
> 
> A related problem is that Guile is littered with functions like
> 
> static int
> print_async (exp, port, pstate)
>      SCM exp;
>      SCM port;
>      scm_print_state *pstate;
> {
>   scm_puts ("#<async ", port);
>   scm_intprint(exp, 16, port);
>   scm_putc('>', port);
>   return 1;
> }
> 
> If the name of a smob type was somehow recorded, the user could be
> allowed to pass 0 in the scm_smobfuns print field and that smob type
> could use a default printer.  (A quick look indicates that this would
> allow us to remove 200-300 lines of smob printer code from libguile!)
> 
> Here is a menu of ways to add names to smobs.  Please pick one of my
> dishes or serve your own!
> 
[snip]

> 2. Create a new version of scm_smobfuns, use the new structure
>    internally, and add a new smob creation function (scm_add_type ()?).
> 
> Backward compatibility is ensured since the old function scm_newsmob
> is kept and still takes the old scm_smobfuns as argument.
> 
> + Gives a chance to clean up both scm_smobfuns and the smob interface
> + Gives an opportunity to add new features to smobs.
> + We could make it easier to add new features in the future (How, though?)
> - Breaks code which looks into the scm_smobs table.  (But such code
>   should not exist, yes?)
> 

I think this is the way to go. Basically, refine the smob interface to
go like this:

smob_t new_type;
new_type = scm_new_smob();
scm_set_smob_print(new_type, print_new_type_func);
scm_set_smob_name(new_type, "new_type");
etc...

and depreciate the current method (though the current method could
easily be implemented around this). While it will eventually require
some rewritting of existing code, it's really not that much, and makes
it much easier to add new bits to smobs (or change the way they're
implemented) in the future.
 
-- 
Greg