Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of t.p.ellison@gmail.com
 designates 66.249.92.171 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding;
        b=jv6Xq6I/A1NNRhV9U6sbsgEu6Js8W4byRVWuDsOFv759aygoEDVwAPpp+JpVTQ+JgDoghO9uRBqyVXOKGtFm0vKJs6ELk7oh5BzfdyjJanHQUNGtWhuNeBxGjgJGAex2NmW1xev79AE8PN8PmG+gcpT5ahNd2YnsDDiI2Wpu0zM=
Message-ID: <4697EC2D.9000205@gmail.com>
Date: Fri, 13 Jul 2007 22:18:37 +0100
From: Tim Ellison <t.p.ellison@gmail.com>
User-Agent: Thunderbird 2.0.0.4 (Windows/20070604)
MIME-Version: 1.0
To: dev@harmony.apache.org
Subject: Re: [classlib][beans] Code seems duplicate for primitive persistence
 delegate
References: <473c46620707112012j34a77b7cldf5f28864700a867@mail.gmail.com>
	 <2c9597b90707120213w220e527au58b9a676b977c9eb@mail.gmail.com>
 <473c46620707122006l1bfcb981k6431c9228a25ff94@mail.gmail.com>
In-Reply-To: <473c46620707122006l1bfcb981k6431c9228a25ff94@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Either way is fine by me.  I don't think there is a significant difference.

Regards,
Tim

Spark Shen wrote:
> 2007/7/12, Alexei Zakharov <alexei.zakharov@gmail.com>:
>>
>> Spark,
>>
>> I don't see many reasons to couple all persistence delegates into a
>> single class. IMO "one  class to one persistence delegate" model is
>> obvious and easy to understand. AFAIU RI implements its persistence
>> delegates in this way. BTW what do you mean by code duplication here?
> 
> 
> For example, looking into the implementation for
> java_lang_BytePersistenceDelegate & java_lang_DoublePersistenceDelegate.
> They both have a instantiate method and an empty initialize method.
> The instantiate method of BytePersistenceDelegate is like:
>        Byte value = (Byte) oldInstance;
>        return new Expression(oldInstance, Byte.class, "new",new Object[] {
> value });
> 
> while the instantiate method of DoublePersistenceDelegate is like:
>        Double value = (Double) oldInstance;
>        return new Expression(oldInstance, Double.class, "new", new Object[]
> { value }); //$NON-NLS-1$
> 
> IMHO, the logic are similar, and can be changed to:
> return new Expression(oldInstance, oldInstance.getClass(),
>                "new", new Object[] { oldInstance });
> The situation exist for other primitive type persistence delegate. They are
> the PDs I listed in my original post.
> 
> The behavior of instantiate() method is unique to each PD and all that
>> we can do is to create a single class with a big big switch that
>> includes the code from all our PDs. Do we really want this?
> 
> 
> I agree with you that a big switch is not a good method. I think we can 
> put
> PrimitiveTypePersistenceDelegate into the persistenceDelegates in class
> initializer instead of a big switch:
>    static PrimitiveTypePersistenceDelegate primitiveTypePD = new
> PrimitiveTypePersistenceDelegate();
>    static {
>        persistenceDelegates.put(int.class, primitiveTypePD);
>        persistenceDelegates.put(double.class, primitiveTypePD);
>        // etc.
>    }
> There is another benefit here: we eliminate type name extraction logic for
> primitive type.
> 
>> IMHO it is
>> not an Object-Oriented way.
>>
>> Sorry if I misunderstand your idea. Please explain in more details if so.
>>
>> Thanks,
>>
>> 2007/7/12, Spark Shen <smallsmallorgan@gmail.com>:
>> > During developing PersistenceDelegate for java.lang.reflect.Field, I
>> find
>> > code duplication in many primitive type persistence delegate.
>> >
>> > There are 8 primitiveType persistenceDelegate:
>> > java_lang_BooleanPersistenceDelegate
>> > java_lang_BytePersistenceDelegate
>> > java_lang_CharacterPersistenceDelegate
>> > java_lang_DoublePersistenceDelegate
>> > java_lang_FloatPersistenceDelegate
>> > java_lang_IntegerPersistenceDelegate
>> > java_lang_LongPersistenceDelegate
>> > java_lang_ShortPersistenceDelegate
>> >
>> > Each of the 8 class has two method: instantiate & initialize, and the
>> logic
>> > of the 2 methods are similar.
>> > IMO, we could use one PrimitiveTypePersistenceDelegate instead to
>> reduce
>> > code duplication.
>> > --
>> > Spark Shen
>> > China Software Development Lab, IBM
>> >
>>
>>
>> -- 
>> Alexei Zakharov,
>> Intel ESSD
>>
> 
> 
>