Noel J. Bergman wrote:
Stefano Bagnara wrote:
Noel J. Bergman wrote:
Stefano Bagnara wrote:
We don't use the duplicate because we can't assume the originalMail is a
MailImpl as the contract is that we receive a Mail object.
Well, then duplicate(...) is pretty useless. :-)
I agree, but I left it for backward compatibility: people may have code
calling that method ;-) Maybe we should mark it as deprecated as
duplicate and duplicate(newName) are only called by tests.
Should we consider adding duplicate to the Mailet API? I had originally
drafted a contructor based approach in my e-mail, and removed it since we have
the same code already in duplicate().
If we could find a way to avoid casting and creating MailImpl objects
all around I would be happy to do this, but unfortunately I think that
currently adding the duplicate method would be not enough because we
need the specific MailImpl class around so we can only be sure we have
it if we use the new MailImpl(Mail original) alternative.
In future we should try to fix this, but we should also add methods to
split a Mail object between recipients, to alias some of the recipients
and so on. Not sure if we should add this to Mail or to MailetContext
but we'll eventually need them (e.g: to correctly support DSN).
I would leave things as is by now.
At the moment, I don't have a strong preference.
MailImpl(Mail) should not create a new name.
Why not?
I think it is safer to generate a new name by default: if you want to
generate a new mail and keep the same name you can do
new MailImpl(orig, orig.getName()).
I prefer the solution I just committed (where the default behaviour is
to generate a new name) because I think it is less error prone
I agree that it is less error prone. I suppose that the question is whether the caller
would expect that they'll get a new name as a side-effect. Perhaps. <<shrug>>
--- Noel
Maybe others should say what they think: personally when I see a
constructor getting an object as parameter I don't assume it will
duplicate the object as is: in this case it does not even take the same
object but an interface implemented by the object so I would not expect
anything without reading the javadocs.
Maybe others follow another workflow, I've not a strong opinion on this.
+1 to the "current" solution
-0 to change the default constructor to not change the name and add
anothr constructor with a boolean to change the name.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
