Thank you all for taking the time to write your thoughts -- they've been very helpful! I hope you'll forgive me for trying to write a response to them collectively touching on the excellent points they raised.
For the record, I'm not a Java developer. I spend most of my time writing in Python by choice. I would like my life less with Java. And I liked my life less with Zope 2 and Zope 3 -- we like the joke that Zope's slogan should be "It *is* easy to use -- you're just stupid." James et al. who said that these are documentation problems. That may very well be, and that's fine. I can live with that answer. I know Python loves duck typing. And duck typing is very powerful for a certain replacement situation: I need to use somebody else's library that expects an object of the class Foo but I want it to work with my class Bar, so I implement the methods and properties in Bar that make it a act like a Foo, and voila! It works. Duck typing is excellent here. Where the weakness of duck typing lies is when I've got somebody else's code that I need it to return a Bar but it returns a Foo. This is where interfaces/components/extension points do very well. If that other person's code instead of saying "construct an object of type Foo" it asks "give me the installed Component that acts like a Foo" and it constructs a Bar object instead. So at my work we developed an app to provide object-level permissions. Ideally, we could ask a User object if it has permission on a certain object via a method in that User object, but absent hacking the User object, that's not going to happen. I can subclass User and add the methods I want -- it will walk and quack like a User. But then I also have to rewrite get_user() so that it returns a ObjectPermissionAwareUser instead of a User. I have to rewrite authenticate() as well. And I have to check the middleware to make sure it uses get_user() instead of returning a user itself. In the end we subclass User and write a method to give us an ObjectPermissionAwareUser when we have a User object. It may very well be that this componentization is all inappropriate for Django. And that's fine. But let it be on the basis of "the benefits we can reap from having componentization exceed the cost of implementation, code complexity, and interface flexibility" rather than adherence to the dogma "Python is purely duck typed so doing anything else would be un-Pythonic" To Jacob: obviously I know your work with Django, so I apologize for the gag reflex. :) I'll try to construct some concrete proposals for improvements to the extensibility of Django without architectural changes and some suggestions for administrative/bureaucratic processes to help canonize some common application pieces to improve interoperability and avoid reimplementation of the same apps over and over. Thanks again, everybody. Have a great weekend! -jag (aka j00bar) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
