james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: AbstractField.PARSER/getParser and dependencies
Date Thu, 24 Dec 2009 17:56:06 GMT
Stefano Bagnara wrote:
> Hi all,
> AbstractField is the abstract class extended by each specific field
> implementation.
> AbstractField, at the same time, provide "static" access to a
> DefaultFieldParser and provides static methods to get a
> DefaultFieldParser and to parse a string into a field using that
> default field parser.
> So every field extend abstractField but AbstractField have a link to
> every of its implementations via DefaultFieldParser =>
> DelegatingFieldParser.
> This smells like a very bad idea. Is it me?

I actually tend to agree.

> So, if you agree this should be improved here are 2 alternative solutions:
> 1) the easy fix would be to move all of the static stuff from
> AbstractField to DefaultFieldParser. As the methods are public static
> methods this would introduce a backward compatibility issue.

I am in favor of this option. We are still in the phase where we should 
be making changes that improve API clarify at the expense of binary 

> 2) Leave only the static methods in AbstractField and create a new
> "AField" (implementing ParsedField) object including the really
> "inherited" stuff and make every implementation extends this AField
> instead of AbstractField. Again this could lead to backward
> incompatibility, but maybe a lot less compatibility issues than the
> previous one.
> Also, after this change DefaultFieldParser and Fields, currently in
> the field package, would be only used by the message package classes,
> so maybe they should be simply moved there.

We can discuss this in the context of MIME4J-129 and MIME4J-131. 
Probably o.a.j.m.fields.* classes should be moved to a separate module 
along with o.a.j.m.message.* and o.a.j.m.storage.* classes.


> Stefano

View raw message