[Mailman-Developers] MemberAdaptor... modifications to API?

[Dale Newfield]

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
needed.

-Dale