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
compatibility.
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.
Oleg
Stefano
