james-mime4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Burrell Donkin <robertburrelldon...@gmail.com>
Subject Re: AbstractField.PARSER/getParser and dependencies
Date Mon, 28 Dec 2009 14:21:09 GMT
On Thu, Dec 24, 2009 at 5:56 PM, Oleg Kalnichevski <olegk@apache.org> 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

Mime
View raw message