First off: +1 and then some from me - this is some great stuff, Malcolm.
On 7/24/06, Malcolm Tredinnick <
[EMAIL PROTECTED]> wrote:
I'm inclined to agree with Bill and Jacob on the is_abstract tag - a flag in the Meta class strikes me as something that could be very easily lost or forgotten.
I had two immediate gut reactions for an alternate syntax -
1) Multiple inheritance:
class Thing(models.Model, models.Abstract):
...
2) A decorator:
@models.Abstract
class Thing(models.Model ):
...
I haven't worked through all the details, but I'm reasonably certain either of these could be used to get around the 'multiple abstract classes' problem. Of the two, I think I prefer the decorator; it seems a little more pythonic, and the multiple inheritance version would require a bit of metaclass magic that I'm not entirely sure I'm comfortable with. However, I think I could happily live with either.
Doesn't scare me. Seems like the natural way to solve the problem. +1
I'm not sure this bothers me. Content types are a fairly 'meta' concept. It seems natural to have it part of the core.
Russ Magee %-)
On Sun, 2006-07-23 at 11:31 -0500, Jacob Kaplan-Moss wrote:
> On Jul 22, 2006, at 9:37 PM, Malcolm Tredinnick wrote:
[...]
>
> > (1) What notation to use to declare a class as abstract? I've
> > thrown out
> > Meta.is_abstract -- any preference for alternatives?
>
> Bill de hÓra suggests ``models.AbstractModel``... hm...
>
> I think I agree with him that ``AbstractModel`` looks cleaner -- I
> like seeing that a model is abstract right there at the top rather
> than having to read down to ``Meta`` to see what's going on.
>
> However, what about the case when I want to do something with more
> than one level of abstract models. Say I want abstract ``Shape``,
> ``2DShape``, and ``3DShape`` classes (where 2D and 3D extend
> ``Shape``)... How would that work with your syntax, Bill?
I'm inclined to agree with Bill and Jacob on the is_abstract tag - a flag in the Meta class strikes me as something that could be very easily lost or forgotten.
I had two immediate gut reactions for an alternate syntax -
1) Multiple inheritance:
class Thing(models.Model, models.Abstract):
...
2) A decorator:
@models.Abstract
class Thing(models.Model ):
...
I haven't worked through all the details, but I'm reasonably certain either of these could be used to get around the 'multiple abstract classes' problem. Of the two, I think I prefer the decorator; it seems a little more pythonic, and the multiple inheritance version would require a bit of metaclass magic that I'm not entirely sure I'm comfortable with. However, I think I could happily live with either.
> I think I'd need to see the code to understand what this extra column
> does, but a "magic" inheritance table seems a little scary to me and
> I'd be inclined against it.
Doesn't scare me. Seems like the natural way to solve the problem. +1
By the way, this introduces something I didn't mention previously (it's
an implementation point): in order for model inheritance to work in this
sort of set up, it needs content types. Content types are a "contrib"
option at the moment. I'm not sure if that worries me a lot or not. It
keeps rattling around in my head, though.
I'm not sure this bothers me. Content types are a fairly 'meta' concept. It seems natural to have it part of the core.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
