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

[Jim Blandy <jimb at savonarola dot red-bean dot com>]

> 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.

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.

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.