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.. >> 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. >>> Would that be too radical a change? > > i'm not a fan so i'm bound to say no :-) Okay :-) >>> 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. Markus --------------------------------------------------------------------- To unsubscribe, e-mail: server-dev-unsubscr...@james.apache.org For additional commands, e-mail: server-dev-h...@james.apache.org
