Property Objects
Matthias wonders why we don't just use objects to model properties. Great question. Internally circumventing any behavior you've added and accessing the underlying field wouldn't be as straightforward, but I'm not sure that's such a big deal. This would certainly make sharing logic between properties a lot easier. I can't think of any reason you'd want to add behavior around dereferencing the property object itself, so I don't have a problem with exposing it as a public field. This uses up a little more memory and isn't quite as straightforward, but I think I still like it.
5 Comments:
So, it occurs to me that if you were going to add some syntactic sugar to the language to better support properties that this would be a much better basis for it than a direct beans style mapping. We'd have a new java.lang.Property<T> (or reuse Reference<T>) type and the compiler would allow you to access the setter and getter transparently as if it were a field. It can never be ambiguous with existing code because it *is* occupying a field of that name. And there is no clunky beans naming convention to tie to the language.
Some sugar for the declaration would help as well... but would simply be turned into a declaration and instantiation of the property holder.
- Pat
Genius!
Wait, how would you replace the property holder then?
C# syntax, then we can also have null-safe aggregation and possibly include JVM managed listeners :-)
The downside of public final property fields is that you can't specify them in an interface. In order to implement an interface through a property object you'd have to introduce a bridge method. Then again, do you _want_ to specify properties in interfaces? It's all confusing.
Post a Comment
<< Home