> 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(); file://overriden
> public String equals(Object obj); file://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.
We can use final only in method parameters declaration to ensure (by
contract) we will not modify them inside the method: this could improve
performance where needed and enforces contract between MailAddress and its
users.
Roberto
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives: <http://www.mail-archive.com/james%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
