Noel J. Bergman schrieb: > 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. > +1 > >>> 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 > > I think we should document it in javadocs... So anyone should have a chance to notice it. If noone read it its not our fault ;-)
bye Norman --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
