Re: Patch to make guile-gtk work with upcoming guile-1.4

["Greg J. Badros" <gjb at cs dot washington dot edu>]

Jim Blandy <jimb@savonarola.red-bean.com> writes:

> > Or we should just decide not to depracate the _mfpe piece.  I think it's 
> > imprudent to require the separate and redundant calls to scm_set_smob_
> > when the common usage suggests the _mfpe interface that permits
> > eliminating those redundancies.
> 
> The original smob interface had one provide a structure of function
> pointers and other info; this structure had to live for as long as any
> objects of that type did.
> 
> In my experience, interfaces like that don't age gracefully.  Over
> time, the set of relevant functions changes.  Usually it's just that
> functions get added, but sometimes functions are superceded in favor
> of newer ones with better interfaces, with the older function kept
> around for compatibility.  Having one setter function for each smob
> function allows the smob definition interface to remain regular as
> these kinds of changes take place.

I'm not arguing for the structure-style interface.  I'm just arguing
about what the front end to client applications should be.

I'll try to make my argument once more (and then quit repeating myself,
I promise):

* the setter-style requires repeating the smob name.  Registering smobs
is typically cut and pasted, thus resulting in a maintenance issue, and
hard to find bugs.

* the setter-style also doesn't make obvious the fact that the special
functions are set exactly once, when the smob is registered, and not
changed.

I believe my varargs style suggestion addresses the extensibility
concerns, avoids redundancy, and encourages proper use at intialization
time (trading them for giving up static correctness checks).

> If you look at GDB and Apache, both of them have traded old-style
> structure interfaces for ones that resemble Guile's newer functions.
> 
> The brevity of code that defines smob types simply isn't of interest
> to me, within reason.  It's run only once, and the time consumed by
> those functions is negligible.

Which is why varargs should be an option.  And since we know it's run
exactly once, the dynamic argument checking we can include suffices.

> I also think that the scm_set_smob_xxx interface is more readable.
> People like Greg Badros may have no trouble remembering what "mfpe"
> means, but in general I think such naming schemes lack gentility.

It was better than the alternative, which was requiring people to
remember the order of the arguments.  It has the additional benefit of
permitting new extensions to choose whether to require people to revisit 
every smob registration call (by changing the name of the exported
function to _mfpek (where k = mnemonic for the new function required by
the smob interface) or by allowing a default for the new function, by
introducing a new _mfpek (leaving the _mfpe intact) that call the _mfpe
and then do the extra setting for the "k" function.

The setter based interface is misleading because it suggests that the
functions can be set at an arbitrary time and repeatedly (instead of
coupling the selection of the special functions with the initialization, 
as it should);  the setter based interface is error-prone because it
requires redundantly specifying the smob ID in a place that is cut &
pasted regularly.

Greg