From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jim Blandy To: "Greg J. Badros" Cc: Marius Vollmer , Mikael Djurfeldt , Ariel Rios , guile@sourceware.cygnus.com, guile-gtk@sourceware.cygnus.com, djurfeldt@nada.kth.se Subject: Re: Patch to make guile-gtk work with upcoming guile-1.4 Date: Mon, 19 Jun 2000 21:54:00 -0000 Message-id: References: <200006020301.WAA23978@erin.galway.com.mx> <87k8flfjyn.fsf@zagadka.ping.de> X-SW-Source: 2000-q2/msg00060.html > 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.