If it could be done that the darned thing didn't eat memory like a fiend in heavily called situations that would make it a better mechansim.  As it is, it is almost the most useless piece of machinery I can think of in Jython.
I do find it odd that people would want to have a different class produced with the same behavior each time.  Oh great, I can modify apple-version1 and it wont affect apple-version100.  I cant think of 0 times where I want to modify the class... usually if there are modifications to be done its going to be to the object.  Ideally in a system you should have one class defining one behavior and not a multitude of equivilent classes offering the same behavior.  Hmmm.... apple-version60090 does the same thing as its predecessors, hmmm... why cant I use apple-version1?

"Stuart D. Gathman" <stuart@bmsi.com> wrote:

But back to the suggestion of "caching" closures. It is true, you
cannot cache the Python class, because it is mutable. HOWEVER, you
could cache the Java component of the Python class, because it is immutable.
The Python class behaviour is still mutable from the Python perspective
by adding method attributes, etc, but by reusing the immutable Java
class component, memory is saved and efficiency improved by not
having to generate more copies.

Stuart D. Gathman
Business Management Systems Inc. Phone: 703 591-0911 Fax: 703 591-6154
"Confutatis maledictis, flamis acribus addictis" - background song for
a Microsoft sponsored "Where do you want to go from here?" commercial.

SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
Jython-dev mailing list

Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around