I probably shouldn't be putting my hat in this ring, but I've never been a big fan of components and interfaces, so I'll provide some of my own thoughts on the subject.
On 9/7/07, Joshua 'jag' Ginsberg <[EMAIL PROTECTED]> wrote: > Problems: > 1) While there is a good degree of drop-in replacability of parts in the > Django stack as I outlined (db backend, authentication backend, etc.) there > is not a clean way for programmers to grok what specific contract various > components have to comply. > > An example: How do I implement a template loader? While I can trace the > behavior of the existing template loaders and try to guess what each of the > methods do and the data that their arguments and return values should > contain, there is not a defined contractual interface for a template loader. > I have no way of knowing that the "filepath" returned from > load_template_source will then be expected to be used by Template's origin > kwarg for reloading the source. The Django team put so much effort into > making these parts componentized without having a component system to > delineate and document contracted interfaces. This sounds like a documentation problem, not a code problem. Template loaders are indeed under-documented, and it seems to me that documentation alone would solve this problem. > 2) There is not replaceability for every component unless such > replaceability is specifically engineered in by the Django team. > > An example: I want to replace the session backend with something not > database bound. I can't until Django commits an extensibility for that > interface. Or I want to have User objects that implement additional methods, > but if I subclass it then all of the other apps won't use instances of my > subclass and won't have access to my extensions. But the same is true of interfaces too. Unless the Django developers expected for something to be extended, they wouldn't provide an interface for it, and thus you'd have to wait for one in order to hook into it. So, while you have a fair point that this is a slight problem, interfaces wouldn't make anything better, so it's a wash. > 3) Without some sort of agreed upon standards to support interaction between > apps, we will not be able to harness the wealth of django apps being written > right now into complete, integrated sites. > > An example: I like Suzy Creamcheese's Blog application but she used > django.contrib.comments in it, and I want Joe Schmoe's slashdot style > commenting system. I also want people who have blogs to be able to post > their own photos, but Suzy Creamcheese's Blog application uses a BlogAuthor > model for biographical data and needs it set as the PROFILE model and John > Shaft's photo gallery application uses a Profile model for biographical data > and also needs it set as the PROFILE model. I can't integrate these without > hacking on them. But if Suzy wrote her Blog application to implement IBlog > and IBlogManager which contained extension points for IComment and > ICommentManager, I could integrate the two systems without having to alter > code. And if both the BlogAuthor model and the Profile model implemented the > same interface then I could still use them together as User can provide the > extension point for that interface. Now, this point I might not be understanding correctly. Are you asking for Django's core to define an interface for each and every potential use someone might find for it? While I can understand the marginal benefit such interfaces might provide, I can't imagine it would be worthwhile to require Django itself to be responsible for all of these. After all, what happens when somebody finds something new to do with Django, or they'd like to add an attribute or method to an existing interface? Well, then we go back to your second point, where we have to wait for the Django team to agree on the changes and implement it, before anybody can do anything. > But I don't think we necessarily want to as a community try to produce > canonical, standard applications and continue expanding contrib for the > utility applications that we all reimplement. But that seems to be almost exactly what you're asking for, by having Django core define all those interfaces. Sure, the interfaces aren't the implementations, so there's nothing to "override", but you're still asking the framework to keep a registry of potential applications. > Perhaps at this young age of Django, it's inappropriate to discuss a > component framework and just rely on the solid engineering to have fuzzily > defined components. But there is not (necessarily) the same sort of > discoverability, rigid contractual obligation, or interchangeability of > these components. Like I said, we have all of the intention of a > componentized framework without any of the actual code to make it work like > one should. And this is the point I usually get to when explaining why I don't like interfaces, and it's at the heart of why I'm not a fan of Java. Essentially, you're asking for the code to make sure that programmers don't make mistakes. You're asking for developers to not have to read (or write!) proper documentation. Personally, I absolutely love Duck Typing, and as long as there's sufficient documentation on what is considered a "duck", then anybody can make their own and we're all happy. I see no need to expect code to be responsible for making sure that programmers are doing their jobs. Again, I probably shouldn't have gotten into this, so please disregard my comments if I'm not making any sense. -Gul --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
