[MERGE] An EmailMessage class for bzrlib (v3)
aaron.bentley at utoronto.ca
Mon Jul 16 13:48:10 BST 2007
-----BEGIN PGP SIGNED MESSAGE-----
Adeodato Simó wrote:
> * Martin Pool [Tue, 10 Jul 2007 00:49:48 -0400]:
>> Martin Pool has voted -0.
>> Status is now: Waiting
>> + 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the bazaar