Seems to me that we either need to add:
sendMail(Sender, Recipients, Message, State, Attributes); sendMail(Sender, Recipients, Message, Attributes);
or make it easier for developers to create a new Mail instance, which pretty much means the same sort of parameters, since Sender and Recipients are read-only properties.
Meanwhile, we can create a MailImpl when we need them.
I don't like the idea of exposing MailImpl, and it seems we're already cheating in this regard. I would prefer deprecating all existing sendMail() methods and instead do:
public interface MailetContext {
Mail newMail();
void queue(Mail mail);
..
..
}I'm not wedded to the two names. I like queue(Mail) over send(Mail) because send() implies a) it's going some place else and b) does not address how message could be placed in other states (like spam, error, whatever).
-- Serge Knystautas President Lokitech >> software . strategy . design >> http://www.lokitech.com p. 301.656.5501 e. [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
