[plt-scheme] An Editors Tale

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.

k

At 01:36 PM 1/29/2004 -0500, Matthias Felleisen wrote:
> For list-related administrative tasks:
> http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>
>Ah, but the problem is that 3% "black holes" that you inject into a program analysis quickly pollute the entire analysis. Do you know of an analysis that copes with higher-order objects (closures) and "black holes" (without additional information about them)? -- Matthias
>
>
>On Jan 29, 2004, at 1:11 PM, Ken Anderson wrote:
>
>>  For list-related administrative tasks:
>>  http://list.cs.brown.edu/mailman/listinfo/plt-scheme
>>
>>Thanks for this detailed reply.  While i've always favored simple flexible languages, you've made their limits clear.
>>
>> From my experience with Common Lisp, MOP level programming is typically done only occasionally to provide a specific capability, such as persistence.
>>
>>To make this quantitative, i looked at Jython 2.1a3, which i have on my machine.
>>I found 234 f*.py iles, with 3389 defs.  Here is a histogram of the top 10 def __... methods:
>>
>>    264  __init__
>>     54  __repr__
>>     12  __getitem__
>>     10  __getattr__
>>     10  __del__
>>      9  __setitem__
>>      9  __len__
>>      7  __delitem__
>>      5  __str__
>>      5  __cmp__
>>
>>Assuming __init__ and __repr__ are OK to define in normal code it means that about 3% of the methods are at the "meta level".
>>
>>Looking at some of the __getattr__ methods i see that they do things like "make this object appear to have all the fields of this other object" which is clever, but too clever to automatically reason about.  So i get Matthias' point.
>>
>>However, if the contamination is only 3%, say 100 methods, maybe some of the libraries can be revised to void this problem.
>>
>>k
>>At 10:03 AM 1/29/2004 -0500, Joe Marshall wrote:
>>>Ken Anderson <kanderson at bbn.com> writes:
>>>
>>>>Do you really mean "most"?
>>>
>>>Matthias has answered some of this, but I thought I'd throw in my $.02
>>>as well.  A couple of months back I was arguing with a Pythonista
>>>about the pros and cons of Python and he challenged me to attack a
>>>`real world' problem and compare it to his Python solution.
>>>
>>>Python has an execution model where the environment is represented by
>>>a hash table (they call this a `dictionary').  It is not uncommon to
>>>manipulate this structure directly to introduce new bindings in a
>>>rather undisciplined way.  The Python class structure is built upon
>>>this model.
>>>
>>>In any class-based object system, there is functionality that is
>>>provided by the class system (hierarchy, inheritance, specialization,
>>>encapsulation) upon which the user implements the behavior of whatever
>>>it is he is modeling.  The Python class system works by creating
>>>dictionaries with `hidden' fields and methods that implement the class
>>>functionalities.  So, for example, all classes have a hidden method
>>>that is called when the interpreter attempts to assign a value to a
>>>class field.
>>>
>>>The problem is that these fields are not particularly well hidden.  It
>>>is quite common to modify the meta-level functionality on a class by
>>>class basis by overriding the __init__, __getattr__, __setattr__,
>>>__getitem__, and __setitem__ fields.
>>>
>>>There really isn't a well-defined reflective meta-level to the class
>>>system.  Pythonistas change the meta-behavior by ad-hoc reprogramming
>>>of the interpreter.
>>>
>>>>If by "translucent" you mean that a class can take on new fields and
>>>>behaviors, i think that can be important for piecemeal growth of an
>>>>application.
>>>
>>>Agreed, and the meta-level should provide a mechanism for doing such a
>>>thing.  The meta-level procedure can have a documented behavior that
>>>can be reasoned about.  But Python does not have this.  The fields in
>>>an object are determined dynamically by the object itself, and the
>>>user may have overridden that method.
>>>
>>>Advanced object-oriented concepts, like mixins, are implemented by
>>>creating a class that when instantiated within an object, calls `eval'
>>>to redefine certain methods within the object.
>>>
>>>>Isn't there a point when a python application, or library can be
>>>>treated as object oriented and then reasoned about?
>>>
>>>Unfortunately, no.  There is no `declarative' class structure.
>>>
>>>>Or is it like TCL where eveything is a string and unimaginable
>>>>string hacking can take place anywhere?
>>>
>>>Pretty much, except that it is all hash tables.
>>>
>>>It reminds me of Lisp in its extreme youth where the value and
>>>function cells were kept on the symbol property list and people felt
>>>free to manipulate them in undisciplined ways.  Its very flexible and
>>>powerful, but the lack of discipline makes it impossible to reason
>>>about.  Since those days we've learned that we can achieve the same
>>>results in a structured manner.  Python is still young.