commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Yu <>
Subject Re: [lang] Proposal for *NEXT* version
Date Fri, 04 Oct 2002 13:35:35 GMT
Hi Stephen,

I also wish to have your hypothetical syntax available in Java.
In Java 3.0, perhaps. :-)

I'd like to hear your comment on the idea I posted in a previous message:

>public class MyClass {
>   private int fAge;
>   private String fName;
>   static {
>     BeanInfoUtils.expose(MyClass.class, "name", "fName", 
> "setNameWithValidation");
>     BeanInfoUtils.expose(MyClass.class, "age", "fAge", "fAge");
>   }
>   private void setNameWithValidation(String name) {..}
>Then, the properties can be accessed by PropertyUtils:
>   PropertyUtils.setProperty(myObj, "name", "John Yu");
>   PropertyUtils.setProperty(myObj, "age", new Integer(42));

I can see the major problem with this approach is, as with all 
reflection-based routines, you'll lose the compile-time checking.

Otherwise, as you said, the other possibility is to do pre-processing in 
the IDEs. A drawback of this approach is you have to give up the 
code-completion facility provided by the IDEs (unless you hack deep enough 
to alter the IDEs' real-time code inspection sub-system). IMO this is a 
significant IDE feature you don't want to give up.

At 05:16 pm 04-10-2002, you wrote:
>We're starting to discuss stuff I've been experimenting with all year. My 
>own Joda project started initially as a way to generate beans from 
>interfaces, adding in other facilities like support for Maps and Lists, 
>plus event handling.
>If I had the chance then I would agree that the declaritive style of 
>defining properties is preferable.
>public class Person {
>   property surname String;
>   property age int;
>The trouble with this is that it requires source code pre generation. The 
>only alternative I've thought of is to write something like an Eclipse 
>plugin that hides the precompilation going on.
>Doing something better with beans/properties seems to be a repetitive 
>requirement. So I'm fully supportive of looking at it.

John Yu                       Scioworks Technologies
e:         w: +(65) 873 5989
w:   m: +(65) 9782 9610

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message