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