Mailing-List: contact mime4j-dev-help@james.apache.org; run by ezmlm
Precedence: bulk
Reply-To: mime4j-dev@james.apache.org
Received-SPF: pass (nike.apache.org: domain of markus.wiederkehr@gmail.com
 designates 209.85.218.164 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :content-type:content-transfer-encoding;
        b=IBRjJgqrAqf3BEdBLO6JlZlbxDoITPsg3DgFQViJZ77Q0xa29NPqbcs0J8na3uvh2o
         bxgBIT3FNmolP7PpKEiph/dHBt+Eud/r/h8xiNkYygbZZ/LkXgPiOmX3Vz5AH3pJTNBR
         L1pEe3u4rLK0HzkbdtXpI2BLpFCJmz6q41WYQ=
MIME-Version: 1.0
In-Reply-To: <f470f68e0902270639s7625eb1dx564f672cd49168c4@mail.gmail.com>
References: <a92573960902260705o2fe3ad0k26486a7ee6343c55@mail.gmail.com>
	 <49A6F46F.6000507@apache.org>
	 <f470f68e0902270639s7625eb1dx564f672cd49168c4@mail.gmail.com>
Date: Fri, 27 Feb 2009 18:14:24 +0100
Message-ID: <a92573960902270914n28d9e9e6qef7d72d40ed80224@mail.gmail.com>
Subject: Re: Interface Field
From: Markus Wiederkehr <markus.wiederkehr@gmail.com>
To: mime4j-dev@james.apache.org
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

On Fri, Feb 27, 2009 at 3:39 PM, Robert Burrell Donkin
<robertburrelldonkin@gmail.com> wrote:
> On Thu, Feb 26, 2009 at 7:58 PM, Oleg Kalnichevski <olegk@apache.org> wrote:
>> Markus Wiederkehr wrote:
>>>
>>> The newly introduced interface mime4j.parser.Field misses some of the
>>> method that where previously available in class mime4j.class.Field.
>>>
>>> The methods are still there but the user has to cast to AbstractField
>>> (with instanceof check of course) to gain access to them..
>>>
>>> Now the question is should we pull up some of the methods, remove them
>>> or move them to other places?
>>>
>>> IMO there are three categories of methods:
>>>
>>> 1) the static methods parse(ByteSequence), parse(String) and getParser()
>>>
>>> These are still accessible but Field.parse() felt natural whereas
>>> AbstractField.parse() feels clumsy in my opinon.. I would prefer a
>>> separate class for these.
>
> +1

I'll look into it tomorrow. The rest is done..

Markus

>
>>> 2) isValidField(), getParseException()
>>>
>>> Pull up?
>>>
>>
>> I personally would rather keep Field interface as generic ad simple as
>> possible. I agree static parsing methods should go to a separate class.
>> isValidField(), getParseException() do not belong to Field, in my opinion.
>
> IMHO they don't really seem to belong in AbstractField either. perhaps
> a subinterface or empty abstract class (ParsedField?) would be better.
>
>>> 3) isContentType(), isSubject(), isFrom() and isTo()
>>>
>>> Feels arbitrary and incomplete.. remove?
>>>
>>
>> +1 to remove.
>
> +1
>
> - robert
>