harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexei Zakharov" <alexei.zakha...@gmail.com>
Subject Re: [classlib][beans] Code seems duplicate for primitive persistence delegate
Date Tue, 17 Jul 2007 13:37:01 GMT
Spark,

Your solution also looks ok to me. However, I agree with Tim that the
difference is not so big. So I'm +0 here. BTW, the current solution
has one significant benefit - it is already implemented. ;)

Regards,

2007/7/14, Tim Ellison <t.p.ellison@gmail.com>:
> 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.


-- 
Alexei Zakharov,
Intel ESSD

Mime
View raw message