commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Niall Pemberton" <niall.pember...@blueyonder.co.uk>
Subject [BeanUtils] Re: svn commit: r295107 - in /jakarta/commons/proper/beanutils/trunk/src:
Date Thu, 06 Oct 2005 14:10:45 GMT
From: "Henning P. Schmiedehausen" <hps@intermeta.de>

> niallp@apache.org writes:
>
> >     protected Object createProperty(String name, Class type) {
> >
> >+        if (type == Object.class) {
> >+            return null;
> >+        }
> >+
>
> When I saw that checkin, I was wondering whether this is not just
> something that plasters over the actual problem. As I can see,
> currently passing a "null" value to a LDB results in
> DynaClass.add(name) instead of DynaClass.add(name, type) being called
> (LDB line 438), which in turn uses new DynaProperty(name), which then
> is mapped inside the DynaProperty class to DynaProperty(name,
Object.class).

Yes this is true. If the first time a property's value is set it is null
then its a  problem because there is no way of determining the type. I did
consider ignoring them and not automatically adding the DynaProperty in that
case - but then this property would be missing when someone processes the
properties of a DynaClass/DynaBean.

Originally one aim of LDB was to automatically instantiate POPJO Bean (or
POJO Bean array) properties - the problem is, there is no way of identifying
when an object is a "bean" as oppose to something else - so it achieves that
effectively by saying well if its not a "DynaBean, Map, List, array,
primitive, Number, String or Date" then I'm going to try and instantiate it.
I believe now that this aim was too optimistic and LDB shouldn't have tried
to achieve that - since it leaves alot of property types that it will
automatically instantiate that you probably don't want it to (including
those of type java.lang.Object). The problem is, since its been released I
don't want to screw up people relying on the current behaviour by taking
whats in createOtherProperty out. Personally I have my own LDB
implementation that does just that - by overriding the createOtherProperty()
method to just return null.

However I think duplicating the check for java.lang.Object types in this
change [at the start of the createProperty() method that you're highlighting
and in the createOtherProperty() method] was a mistake so I've removed the
one from the createProperty() method - that way people just have to override
the createOtherProperty() method to implement alternative behaviour.

> How does this differ from set("foo", new Object()); ?

Well here you're explicity setting a property value to java.lang.Object -
rather than LDB automatically instantiating a java.lang.Object for you.

> The use of "Object" here is a bit obfuscated IMHO. Maybe we should use
> a "NullType" marker object?


I did ponder using an "UndefinedType" for a DynaProperty that was
automatically added via set("foo" null) - but that led me to think that if a
"none null" value was later set should I replace the DynaProperty with
"UndefinedType" with one with the class of the new value? That seemed to
open up a more complex route (modifying DynaProperty's), so it seemed best
to keep it simple and leave it as it was. Also,  an "UndefinedType" creates
a headache for someone retrieveing and processing the properties of the
DynaClass.

IMO there isn't an ideal route for properties that are first set with a
value of "null" and so would probably favour not doing anything more - if
someone wants to avoid this happening, then all they need do is add a
DynaProperty with the appropriate type to the LazyDynaClass first.

Thanks for your comments.

Niall

> Best regards
> Henning



---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message