On Wed, 2009-02-25 at 16:06 +1100, Ryan Kelly wrote: [...] > > The use-case for the pure-Python inheritance that has been floating > > around is the case when you want to, say, use a different User manager > > in your own views. You don't want to change the auth app's behaviour in, > > say, admin, but you'd prefer a different default when you're using it. > > So you subclass User, using Python-only inheritance, add a new default > > manager and then actually use the subclass, rather than User in your > > code. > > ....because this sounds like exactly how I want to use this feature. I > subclass auth.User and add my own managers/methods/etc, and use this > subclass in my own code. But if someone creates a new instance of > auth.User via the standard class, it should also show up in queries > posed through my subclass.
Okay, so that's the situation I would expect. It doesn't automatically replace all usages of User with your subclass (which is what I thought you were going for). It simply means the subclass is a proxy view of the same persistent data as the main class. That should be just a matter of pointing both models to the same database table, etc, as you've done. > > Likewise, if I add a new user through my special subclass, it will show > up as an ordinary user to e.g. the admin interface. > > So I'm not trying to add anything magical - the "virtual subclass" is > simply a "facade" or "wrapper" around the data in the base class table > that presents a modified interface. Yikes, there's that naming problem > again... If you what you're seeking a word for is to describe the style of subclassing, call it a proxy class, since it stands in for the original model. Certainly within the Django documentation, I'd like to avoid words like "facade" or "virtual". The latter has the normal direction reversed (in other languages, it's applied to ancestor classes, so will cause at least a slight brain hesitation when people read it), the former is not a common enough word to be clear to the thousands of people reading the docs who don't have English as a first language. "Proxy" meets the "common enough" test, for my tastes, at least. You run across proxies for everything in computer science, particularly web-exposed products. if somebody doesn't already know the word, they need to learn it pretty quickly in any case. > > > Still, I wouldn't let that hold things up. I'll think about it and come > > up with a name later on, unless a better option appears beforehand. > > Originally I named it "use_superclass_table" but decided that was just > too ugly to deal with. "interface_only"? Glad not to be the one stuck > making that decision :-) Again, "interface" has that not particularly common touch to it. We should try hard to stick to really obvious words to describe things (and "interface class" is already used in OO for something that definitely isn't the child class, so the confusion problem, again). Yeah, naming stuff is hard. We knew that already. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
