On Tue, Jan 6, 2009 at 8:34 PM, Markus Wiederkehr <markus.wiederk...@gmail.com> wrote: > On Tue, Jan 6, 2009 at 9:09 PM, Robert Burrell Donkin > <robertburrelldon...@gmail.com> wrote: >> On Tue, Jan 6, 2009 at 7:31 PM, Markus Wiederkehr >> <markus.wiederk...@gmail.com> wrote: >>> Would it be a problem to change the return type of Message.getSubject? >> >> i'm not a fan of the legacy message API so i generally keep quiet... > > May I ask why not? I think it has so much potential..
potential, yes but it's not an itch of mine... >>> Markus >>> >>> On Sun, Jan 4, 2009 at 7:49 PM, Markus Wiederkehr >>> <markus.wiederk...@gmail.com> wrote: >>>> I've noticed that Message has a method getSubject() that returns the >>>> subject as UnstructuredField. >>>> >>>> In my opinion it would be more practical if getSubject() simply >>>> returned a string. The existing getSubject() method would not >>>> necessarily have to go; it could also be renamed in getSubjectField() >>>> or something like that. >> >> IMHO being able to access the raw meta-data is important but is a low >> level operation. for low level operations, i favour conciseness over >> convenience. so i'd say some sort of generic API would be better than >> getSubjectField. > > Of course it is possible to use Entity.getHeader() and > Header.getField() or getFields() to get low-level access to any header > field. The user only has to know what concrete Field subclass the > result can be cast to. This would be the generic API, I'm not sure if > it could be called concise though. yep FWIW the casting has always felt clumsy to me... <snip> >>>> Furthermore I think that Message should have more convenience methods >>>> like that, getDate(), getFrom(), getTo(), etc.. >> >> quite possibly: when going down this route it's a bit hard to know >> just when to stop but IMHO providing convenient access to standard >> fields is appropriate for a high level API. > > Standard fields, like you say. Open for expansion on demand. you might be able to learn some lessons by taking a look at the - not entirely satisfactory - approach we took in the org.apache.james.mime4j.descriptor package - robert --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
