Noel J. Bergman wrote:
Stefano Bagnara wrote:
Considering that the newName method is currently called only during the
creation of a new MailImpl object I think that a third solution would
be better.
This is just using a constructor instead of the duplicate() call. But OK.
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.
Add a constructor to MailImpl:
public MailImpl(Mail original) that simply create a newName
and then calls this(original, newName(original));
MailImpl(Mail) should not create a new name. If we want to use the contructor
approach, go with the same pattern:
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()).
MailImpl(Mail orig) { this(orig, false) }
MailImpl(Mail orig, boolean newName) { ... }
Work for you?
--- Noel
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 than the
boolean value.
My idea is supported by the fact that currently we only need the
constructor that generate a new name and we would never use the default
one (that could lead to problems because you start having 2 Mail objects
possibly different and sharing the same key).
What others thinks?
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
