Wonder what Joe thinks of this properties solution
Kevin Wong
Steve Lewis
I have to ask the crowd:
Does the anonymous inner class in Java read elegantly or simply?
Are you excited by the idea of adding more anonymous inner classes to your Domain Model?
And how does the possibility of adding a new closure syntax impact your view of anonymous inner classes?
I'm not push-polling here. I think the properties solution in the link provided is interesting and possibly valuable but it presents an opportunity to consider these questions, and I'm interested in the answers.
--
SteveL
Joe Nuxoll (Java Posse)
- Joe
On Jun 27, 9:08 am, Kevin Wong <kevin.peter.w...@gmail.com> wrote:
> https://bean-properties.dev.java.net/
Casper Bang
on the JSR-295 mailing list which you might want to follow:
https://beansbinding.dev.java.net/servlets/SummarizeList?listName=users
/Casper
Kevin Wong
already rolled our own bean binding framework that we submitted to
JSR295's expert group for their reference. I don't know how much of
it, if any, they used.
Shai Almog seems pretty adamant that a binding framework based on his
bean properties library would be far superior.
Casper Bang
> Shai Almog seems pretty adamant that a binding framework based on his
> bean properties library would be far superior.
Right. Meanwhile, I'm rooting for Rémi Forax and his attempt to get
native property support in Java.
http://weblogs.java.net/blog/forax/archive/2007/06/beansbinding_go.html
/Casper
Curt Cox
property support to the language. The Bean Properties project makes
some mistakes, but is currently the most well developed implementation
of the property objects concept. Any such project is going to succeed
or fail, based on its adoption by the Swing team and its integration
with JavaFX. Unfortunately, I don't think this approach is on their
radar.
"Does the anonymous inner class in Java read elegantly or simply?"
They aren't bad, but most of the time it is better to use named
classes. Named classes:
1) Are more friendly to java.io.Serialization.
2) Are more likely to be well documented and helpfully named. For
whatever reason, people writing anonymous classes tend to think that
the code itself provides adequate documentation.
3) Provide more readable stack traces.
4) Allow you to favor static classes.
5) Make the code where they are being used more readable.
"Are you excited by the idea of adding more anonymous inner classes to
your Domain Model?"
No. I don't really see where you're going with this. Perhaps you can
elaborate.
"And how does the possibility of adding a new closure syntax impact
your view of anonymous inner classes?"
It doesn't. It probably should, but it doesn't.
Steve Lewis
"Are you excited by the idea of adding more anonymous inner classes to
your Domain Model?"
No. I don't really see where you're going with this. Perhaps you can
elaborate.
I know at least one person who likes anonymous inner classes for providing encapsulation without hiding the implementation details from the usage context. The argument relies heavily on pointing to Swing's usage. I suspect the reliance on anonymous inner classes in this proposal will resonate for those people but I wanted a larger sample.
--
SteveL