Roberto Lo Giacco wrote:
> Take a look to the class I sent you: it's behaviour when only the getHost()
> and getUser() methods are used is pretty similar to your MailUtils, but it
> adds the ability to deal with MailAddress objects instead of String objects.We
> are talking about APIs not about implementations so think to the awt
> Point/Dimension classes: they just acts as wrappers for two integers but it's
> the correct way because if you have two integers strictly related and a couple
> of actions to execute over them so it's just what you need to start a class!
> In JNDI we have Name for example that is a nother way to see a String
> representing a name in a namespace: in JAMES we have MailAddress or whatever
> we want to call it which is another way to see a String representing an email
> address.
> So we can clarify the APIs allowing to specify an email address both by its
> string representation AND by our specifical class allowing transparent switch
> between them.
I definitely do not like overloading methods with both MailAddress and
String... it creates many extra methods of identical functionality,
which while convenient, in my opinion it tends to clutter up an API.
> About the personal field I think we shouldn't throw it away only because we
> don't see it's use at the moment (adding a tail to the message with the sender
> name or just using that info into the logger are a start) but we have to
> retain it only because it is an information bounded into the mail so available
> to everyone want's to use it. IMO personal name is another reason to switch to
> MailAddress and I'll implement the class so it will not worth if you doesn't
> use it at all.
It's not a question of throwing away the personal field... we never get
it!
I think it would be better to strip all static methods (and drop the
personal field since we never get it) and just leave this as a simple
class with the following method signature:
public MailAddress(String address);
public MailAddress(String user, String host);
public String getUser();
public String getHost();
public String toString(); //overriden
public String equals(Object obj); //overriden
This keeps the class easy to use and still relates user and host, with
the single String constructor to make it easy to convert to and from
String.
I also don't think we want to make anything final in this class. This
is leveraging an optimizer specific trick, and while it's unlikely,
other optimizers might not care about the final keyword. Meanwhile, the
final keyword definitely affects the API.
Serge Knystautas
Loki Technologies
http://www.lokitech.com/
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
