Atom Feed SITE FEED   ADD TO GOOGLE READER

Bean-independent Properties

I just posted the first draft of a proposal for Bean-independent Properties for the Java language.

This started when I was CC'd on email from Mikael Grev who prefers bean-attached properties. I prefer the opposite, so I figured I'd make my preference concrete. This is quite similar to an implementation by Remi Forax, who seems like a pretty damn smart guy from what I've seen so far.

What does it look like to use?
  Customer customer = ...
  String city = customer#city;
  customer#city = "San Francisco";


And to declare?
  public property Property<Customer,String> city
      = new BasicPropertyBuilder(property(""))
          .nonNull()
          .observable(##propertyChangeSupport)
          .build();


Read the Full Proposal.

# posted by Jesse Wilson on Sunday, September 30, 2007

I would prefer a separation between the regular code and the meta level. How about putting Property in the java.lang.reflect package? To get to an instance of java.lang.reflect.Property, you could use Customer#city, whereas aCustomer#city would access the property's value for a particular bean - syntactic sugar for Customer#city.get(aCustomer) or .set(aCustomer, value) depending on how it is used. (Note that this would suggest that the setter should return the new value, not the old value, to make it analogous to how Java's assignment expression works.)

As for the keyword, could declaring a propery be made simpler? For example, how about this:

public class Customer {
public Long #id;
public String #city;
}

Customizing properties could still be done using anonymous classes like you suggest:

public class Customer {
public Long #id
extends NonNullProperty;
public String #city {
String get(Person bean) {
// do something clever...
return bean.city;
}
};
}

Oh, and could you also try to push for real fine-grained notifications for observable lists and sets? ;-)

# posted by Blogger Boris Bokowski on September 30, 2007 11:23 PM

Boris, I love this syntax:
public Long #id
So much that I'm definitely gonna use it!

Unfortunately I don't think it's prdudent to use the same syntax for both Property access as value access:
Customer#city vs. aCustomer#city
This type of name causes problems. I'd rather do it the way that static methods and fields work in Java, where you can use either an instance of class literal to qualify them.

# posted by Blogger swankjesse on October 1, 2007 8:55 AM

Hey Jesse,

Could you expound a bit on what it is you prefer about bean-independent properties versus bean-attached properties?

Just curious!

-Ken

# posted by Blogger Ken on October 2, 2007 5:45 AM

Post a Comment