[Mailman3-dev] Mailing list attributes: immediate access, or proxied?

[Robin Munn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

During the PyCon sprints, we created a MailingList object in
src/mailman/mlist.py which has __getattr__() and __setattr__() methods
to set mailing list attributes such as "max_hold" or "enable_archives".
I've been rethinking that decision; I think another method might be
slightly better. Instead of using straight attribute access, I think it
might be better to use a proxy object. Call it "attr", or maybe just
"a". Possibly both could be allowable. Thus to create a non-archived
mailing list, one would do something like this under the current scheme:

~    mlist = MailingList(...)
~    mlist.enable_archives = False

Whereas what I'm wondering is whether we should do it like this:

~    mlist = MailingList(...)
~    mlist.attr.enable_archives = False

Or possibly use a different name than "attr":

~    mlist = MailingList(...)
~    mlist.opts.enable_archives = False

The proxy object would be simple:

~    class AttributeFetcher(object):
~        def __init__(self, parent):
~            self.parent = parent
~        def __getattr__(self, attrname):
~            # Same code as is currently in MailingList
~        def __setattr__(self, attrname, attrvalue):
~            # ditto

~    class MailingList(object):
~        .
~        .
~        .
~        def __init__(self):
~            self.attr = AttributeFetcher(self)
~        .
~        .
~        .


Pros of what we have now:

~    * Simple. Easy to understand. Easy to read.

Cons of what we have now:

~    * Methods and mailing list attributes are living in the same
namespace. Could hit collisions.


Pros of the second method (mlist.attr.some_option):

~    * Still simple, still easy to understand.
~    * No namespace collisions.

Cons of the second method:

~    * More typing involved.
~    * Two dereferences instead of one -- Law of Demeter says this smells.


I'm not sure I entirely believe the last con, though: the Law of Demeter
is only intended to apply to coupling between distinct objects. Here,
AttributeFetcher is a helper class specifically designed for
MailingList; it *should* be tightly coupled.

What do you think?

- --
Robin Munn
rmunn at pobox.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCSOy36OLMk9ZJcBQRAgNpAJ9bL94QqLrra1oOyqLj5Pm/gPZk1gCeJixc
cBQCDQ3vIkc/lCtdQMFxTcE=
=b/X5
-----END PGP SIGNATURE-----