The one-giant-object approach
Gentlebeings,
I'm trying to hook up the object-relational mapper I've worked out to mailman, and I'm encountering an issue I'd appreciate feedback on.
Take MailList. Aside from its own namespace, it mixes in 11 other classes, leading to 255 names if you dir(list).
Is this large, flat namespace a preference? It seems to me like it mixes together many bits of functionality that aren't always needed by whatever code needs a 'list'.
It seems to me that if things were broken up a little bit they'd be conceptually easier to follow, and it'd be easier to make improvements.
While I understand that a unified DB likely won't make it into 2.2, I would like to break out some functionality, and I just wanted to make sure that keeping a flat namespace wasn't a design goal.
Thanks,
~ethan fremen
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Oct 19, 2006, at 3:45 PM, emf wrote:
Take MailList. Aside from its own namespace, it mixes in 11 other classes, leading to 255 names if you dir(list).
Is this large, flat namespace a preference? It seems to me like it
mixes together many bits of functionality that aren't always needed by whatever code needs a 'list'.
Personally I'm not very fond of the mix-in architecture of the
MailList classes. I believe it was originally intended to allow for
easy addition of functionality, but it just makes things more
complicated than necessary.
It seems to me that if things were broken up a little bit they'd be conceptually easier to follow, and it'd be easier to make
improvements.
I agree, but I think that will be difficult to impossible for 2.2.
OTOH, you can ignore many of the MailList attributes. If you emulate
what MailList.Save() does, you'll be fine. OTOH, ignore anything
that starts with an underscore or that is a MethodType.
While I understand that a unified DB likely won't make it into 2.2, I would like to break out some functionality, and I just wanted to make sure that keeping a flat namespace wasn't a design goal.
BTW, I'd love to get a database approach for mailing list data,
rather than the current pickle approach. What we've always taken off
the table for 2.2 is the unified user database (i.e. one record per
user instead of one record per user per list). Even if all that data
was stored in a database, it would still be great if you could access
those values via attribute access syntax off the MailList instance.
Given the ability of Python to interpose attribute access, I think
that's possible. That does point to a flat namespace as a
simplifying principle.
- -Barry
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin)
iQCVAwUBRTgy0HEjvBPtnXfVAQJmxAQAsbBwBbwbpdaLYfvFIGSdJzqRJRVOYqbW /iE51+WplcGHqjECGMitKSaoSTkRhH1bv6Wbmw++fe6ggEevFHUWpQ6eLqfx0Bup YXGaWpuUBcuRRNGmkxXu2UHygt8/TJoxUtIPZfa/GeDr0Mmr/YOSDLNVwB8W5MCL sObBU0xJhfw= =6NVN -----END PGP SIGNATURE-----
participants (2)
-
Barry Warsaw -
emf