On Thu, Dec 24, 2009 at 5:56 PM, Oleg Kalnichevski <[email protected]> wrote: > 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.
+1 >> 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. +1 >> 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. +1 - robert
