On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]
> wrote:
Hey! Great idea! +1 :-)
Hadn't considered using the Meta class. +1 on this idea.
Related note that just occured to me: is there any intention to extend query terms with this attribute-based inheritance syntax? i.e., is something like:
Place.objects.filter(restaurant__chef_name='Bork')
going to be possible? And if so, what about:
Place.objects.filter(Q(restaurant__chef_name='Bork') | Q(baseballfield__home_team_name='Red Sox'))
Any comments?
Grrrr... I am now holding you _personally_ responsible for the fact that I have a Billy Joel song going through my head. :-)
Other than toy cases, I don't actually have a strong use case for this kind of situation; however, I won't presume to represent the world community of developers out there. I would only offer that the existence of CORBA's narrow() is proof of the potential for a need (my god... I'm defending the design decisions of the OMG... time to kill myself... :-)
Interesting idea, but one that I would think could be added transparently as an optimization post facto. IMHO, getting inheritance working is a more immediate priority.
Sad, but true.... :-)
I think this is a reasonable approach. I doubt it would be a showstopper (if only because it can be implemented by end users without too much drama), and I don't have an actual use case myself that would require this feature.
I mentioned it because (1) a toy example jumped to mind immediately, (2) I'm pained to not provide a feature because _I_ don't have a need for it, and (3) I could see that isinstance() was really just a booleanized form of narrow(), so most (if not all) of a narrow() implementation would be required to implement isinstance(), and if this was the case, I figured it might be worthwhile exposing the useful bit as API.
Always a pleasure.
Russ %-)
> Obviously, I'd still prefer an _actual_ duck, but this seems a
> reasonable alternative in an duckless world.
I could subclass everything from Duck if you like. Poor man's duck
typing. :-)
Hey! Great idea! +1 :-)
I haven't worked out the API for specifying the attribute here, but
that's minor. Basically, we need something on the sub-class to say "use
this attribute name in the parent(s)". An attribute in the Meta class is
probably the solution, I guess. We already need to have an attribute for
specifying database column(s) back to the parent(s). Failure to set the
attribute and getting a name clash is a validation error.
Hadn't considered using the Meta class. +1 on this idea.
Related note that just occured to me: is there any intention to extend query terms with this attribute-based inheritance syntax? i.e., is something like:
Place.objects.filter(restaurant__chef_name='Bork')
going to be possible? And if so, what about:
Place.objects.filter(Q(restaurant__chef_name='Bork') | Q(baseballfield__home_team_name='Red Sox'))
Any comments?
> hrm... -0. I would have thought that a single isinstance() would be a
> better idea than a range of is_XXX() functions. e.g.,
>
> p.isinstance(Restaurant)
You might be right, I may be .. (wait! Let's not finish that thought.
Billy Joel has the copyright).
Grrrr... I am now holding you _personally_ responsible for the fact that I have a Billy Joel song going through my head. :-)
I feel I can live without anything resembling narrow() -- or C++'s
dynamic_cast, for those more familiar with that language -- because I'm
not convinced there is an important use-case. However, if we leave it
out, it does makes accessing the beer_price attribute, wherever it may
live a little harder. It's also dangerous for me to be projecting my
usages onto the world wide group of developers. I have some experience,
but not *that* much. So, you probably have a point.
Other than toy cases, I don't actually have a strong use case for this kind of situation; however, I won't presume to represent the world community of developers out there. I would only offer that the existence of CORBA's narrow() is proof of the potential for a need (my god... I'm defending the design decisions of the OMG... time to kill myself... :-)
In passing, overriding __getattr__ isn't an ideal solution, either,
because it doesn't work well with lazy attribute resolving. I tried for
a while to make that work nicely, but never came away happy. (Although,
as I write this, it occurs to me that with introspection and caching
which models have which fields, we would only examine the "right"
tables. Hmmm.)
Interesting idea, but one that I would think could be added transparently as an optimization post facto. IMHO, getting inheritance working is a more immediate priority.
> My crystal ball forsees
> complaints if it is omitted.
My crystal ball says the complaints won't stop if it is, though. :-)
Sad, but true.... :-)
I think the answer to the first question is "no", so I don't feel too
unhappy putting it in the "later" basket for now.
I mentioned it because (1) a toy example jumped to mind immediately, (2) I'm pained to not provide a feature because _I_ don't have a need for it, and (3) I could see that isinstance() was really just a booleanized form of narrow(), so most (if not all) of a narrow() implementation would be required to implement isinstance(), and if this was the case, I figured it might be worthwhile exposing the useful bit as API.
Thanks heaps for all the feedback, Russ. Helps a lot.
Always a pleasure.
Russ %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
