[Mailman-Developers] MemberAdaptor... modifications to API?
Fri, 23 Aug 2002 17:09:56 -0400 (EDT)
On Tue, 20 Aug 2002, Barry A. Warsaw wrote:
> DN> I guess what I'm suggesting is that instead of using this
> DN> accessor like this: mlist.getMemberOption(addr,
> DN> mm_cfg.OPTINFO['plain']), it be used like this:
> DN> mlist.getMemberOption(addr, 'plain'), and inside
> DN> OldStyleMemberships it does the mm_cfg.OPTINFO lookup. That
> DN> way a Membership adaptor doesn't need to know that option "8"
> DN> is DisableMime (but if it wants, it can find that the value
> DN> option 'plain' is found by &'ing it's internal options
> DN> bitarray with the value 8).
> The problem that I have with this approach is that it's much easier to
> let a typo like mm_cfg.OPTINFO['plian'] slip through than to use a
> symbolic constant. E.g. tools like Pychecker can verify that the
> constant exists, but can't really do much with the string.
So instead of accessing it through mm_cfg.OPTINFO, let's make a function
that verifies that its one argument is in mm_cfg.OPTINFO, if so
returning it's value, if not throwing an appropriate exception.
That way you'd at least get a runtime error instead of a silent failure.
> DN> I might alternately suggest that the values be bit locations,
> DN> and the values to & be figured out with (1<<BitPosition), so
> DN> that at least the "option numbers" be ordinal rather than
> DN> powers of two. That is more much less important (more a
> DN> stylistic thing), though.
> That's not a bad alternative, and it preserves my desire for constants,
> but I'm not sure it helps you much though. You still need to know what
> values correspond to which options.
Right. It's not a full solution, just (IMHO) better than what we've got
> Something like this is probably going to be too late for MM2.1.
That's what I figured.
> The best thing to do is to work out the patches and upload them to
> SourceForge. At least there, they won't get lost in an inbox, and we
> can re-examine them when MM2.1 final is released.
I'm just gonna code them up in a CVS checkout, so that (barring hairy
conflicts) I'll be able to generate a patch against the baseline whenever