Why methods shadow JavaBean properties?

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Why methods shadow JavaBean properties?

Daniel Dekany
What's the rationale behind this? For example, if I have int getFoo()
and int foo() in the same class, then in FTL someObj.foo will return
the foo method (the method itself as a value) instead of the property
value. You also face this same problem if you only have foo() which is
however the property reader (because BeanInfo.getMethodDescriptors
will not exclude the methods that BeanInfo has already detected as
property readers or writers). I think that the property should have
priority in both cases. Do I miss some use-cases here where it's
better the way it is? (Of course, if I will fix this, it will be with
a new BeansWrapper setting that will default to the current behavior.)

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel
Reply | Threaded
Open this post in threaded view
|

Re: Why methods shadow JavaBean properties?

Daniel Dekany
Sunday, December 12, 2010, 2:36:32 PM, Daniel Dekany wrote:

> What's the rationale behind this? For example, if I have int getFoo()
> and int foo() in the same class, then in FTL someObj.foo will return
> the foo method (the method itself as a value) instead of the property
> value. You also face this same problem if you only have foo() which is
> however the property reader (because BeanInfo.getMethodDescriptors
> will not exclude the methods that BeanInfo has already detected as
> property readers or writers).
[snip]

OK, this last is not true in this form. After all, if there is a
BeanInfo class for a class, it has full control over what methods are
exposed, and hence it might as well exclude said methods. But for
example the automatically made BeanInfo returned by the Introspector
doesn't exclude methods with clashing names, so if we take that as the
example of how a custom BeanInfo should look...

--
Best regards,
 Daniel Dekany


------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
_______________________________________________
FreeMarker-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freemarker-devel