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().
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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
