[plt-scheme] An Editors Tale

This is a great reply, as i've just asked Eric Raymond to speak at BBN.
So far, i've loved reflection, (JScheme lives on it) but you've show me its limits.  If we could turn this into a talk for Lightweight Languages 4, that would be great!.

k
At 04:38 PM 1/29/2004 -0500, Matthias Felleisen wrote:

>On Jan 29, 2004, at 4:27 PM, Ken Anderson wrote:
>
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>>I was hoping that with only ~100 methods (maybe fewer are the real issue) it might be possible to rewrite the classes to avoid these meta hacks.
>>Maybe the Scheme astronomers can classify the black holes into a few types that can be delt with somehow to make analysis possible.  Of course, this might be harder than it looks .  I just didn't want you guys to give up on Python, until, well now.  It would be cool if Scheme guys could make Python a better language.
>
>Jeremy and I had a brief discussion on this at LL3. I believe that the features I dislike are hard-wired into Python and are acclaimed to be major components. So I doubt that the Python community is interested in listening to people like us.
>
>For another example of how much Pythonistas love this stuff, see
>
>  http://www.linuxjournal.com/article.php?sid=3882
>
>A relevant quote:
>
>
>"I had already designed and written the three object classes (that's what took four days, most of it spent getting the layout of the widgets just right). Each had a method that caused it to pop up a GUI edit panel to modify its instance data. My last remaining problem was somehow to transform the dead data in this Python initializer into live objects.
>
>I considered writing code that would explicitly know about the structure of all three classes and use that knowledge to grovel through the initializer creating matching objects, but rejected that idea because new class members were likely to be added over time as the configuration language grew new features. If I wrote the object-creation code in the obvious way, it would be fragile and tend to fall out of sync when either the class definitions or the initializer structure changed.
>
>What I really wanted was code that would analyze the shape and members of the initializer, query the class definitions themselves about their members, and then adjust itself to impedance-match the two sets.
>
>This kind of thing is called metaclass hacking and is generally considered fearsomely esoteric--deep black magic. Most object-oriented languages don't support it at all; in those that do (Perl being one), it tends to be a complicated and fragile undertaking. I had been impressed by Python's low coefficient of friction so far, but here was a real test. How hard would I have to wrestle with the language to get it to do this? I knew from previous experience that the bout was likely to be painful, even assuming I won, but I dived into the book and read up on Python's metaclass facilities. The resulting function is shown in Listing 3, and the code that calls it is in Listing 4.
>
>Listing 3
>
>Listing 4
>
>That doesn't look too bad for deep black magic, does it? Thirty-two lines, counting comments."
>Eric Raymond
>
>-- Matthias