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]

Name of smob type, new field in scm_smobfuns?


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