[MERGE] An EmailMessage class for bzrlib (v3)

Aaron Bentley aaron.bentley at utoronto.ca
Mon Jul 16 13:48:10 BST 2007

Hash: SHA1

Adeodato Simó wrote:
> * Martin Pool [Tue, 10 Jul 2007 00:49:48 -0400]:
>> Martin Pool has voted -0.
>> Status is now: Waiting
>> Comment:
>> +        self._init_message(self, from_address, to_address, subject, body)
>> +
>> +    @staticmethod
>> +    def _init_message(msg, from_address, to_address, subject, body=None):
>> It does seem pretty strange to have a static method that takes (usually)
>> an instance of this class as its first parameter, and then switching on
>> isinstance within it is also a bad sign.  To me it looks like rather than
>> subclassing this type, we should have our own class which acts as a facade
>> to one class or the other.
> Hm. This seemed the lesser of two evils to me. Let me see if I understand
> your facade concept: a class that, depending on whether there's an attachment
> or not, is internally a MIMEMultipart object, or a simple Message.

I believe Martin was referring to the Fasçade design pattern:

It doesn't imply that the fasçade must contain a member of either class,
although it's certainly a possibility.

I would actually advise against it, though.  I think if we want our own
email class, it should only produce a Message or MIMEMultipart when
generating its final output.

> I can think of two ways of doing this:
>   * try to behave like a true Message/MIMEMultipart, that is, the
>     creator of the object can do msg['From'] = 'Foo', etc., and use all
>     the methods available in the standard Message/MIMEMultipart classes.
>     For this, I guess one would have to play with __getattr__().

Trying to keep the API of the original library would be at odds with the
intent of Fasçade, which is to hide the original API behind something

Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the bazaar mailing list