This is the mail archive of the guile@cygnus.com mailing list for the guile project.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
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!
1. Add new name field to scm_smobfuns.
typedef struct scm_smobfuns
{
SCM (*mark) SCM_P ((SCM));
scm_sizet (*free) SCM_P ((SCM));
int (*print) SCM_P ((SCM exp, SCM port, scm_print_state *pstate));
SCM (*equalp) SCM_P ((SCM, SCM));
char *name;
} scm_smobfuns;
Backward compatibility is ensured since the name field will be
initialized to 0 in old code IF that code declared the smobfuns struct
as static.
- It is a bit ugly to have the name of the type as the fifth element.
- Breaks code which has declared the smobfuns struct as global
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?)
3. Add a new table of names in parallel to scm_smobs and add an extra
smob creation function.
(+) Keeps the internal representation (scm_smobs) the same