I don't think they are syntactic sugar, like I've mentioned previously a Property isn't simply a wrapper around getFoo/setFoo methods, they are a separate construct that does allow for type safety of some state. If you're a component designer and you come across a class with String getFoo(); void setFoo(Integer val) what do you do? Do you treat Foo as a single read-only property of String or do you not show it at all?
Properties are a 1-to-1 relationship of a classes member and the state it's representing, currently we don't have this support in Java. Trying to traverse the object graph to find what members are properties is currently painful, I wrote an example the other day to explain to a friend this fact (attached), if you never have to write this sort of code then you're extremely lucky. Registering a listener in Java isn't the main problem, it's a real problem for a component author where you have to maintain a list of listeners, then call them when the event occurs. You end up with at least 15 lines of code, take a look at javax.swing.AbstractButton.fireActionPerformed(ActionEvent) as a classic example of this. To properly get closures, you need function pointers, and that's why we need them in Java, and with function pointers we can implement proper events fairly easily. I don't want to assume, but are most people who couldn't care for events/properties server side developers? The real benefit to these features is with statefull code, not so much with stateless, since stateless code can't really listen to events in the first place. -Brett On Wed, Nov 5, 2008 at 12:10 AM, Jess Holle <[EMAIL PROTECTED]> wrote: > Brett Ryan wrote: > > So hey, now we have PEDL, the four language features required to power > Java ahead of C#. > > Properties, Events, Delegates and Lambda expressions :) > > > I won't say these aren't much better in C# than in Java. > > I will say the examples given in posts thus far haven't really proven this > to me. += syntax for event listeners and shorthand for getter/setter > accessors? Yawn -- not bad but nothing I'd get excited about. Syntactic > sugar that saves a little typing doesn't quite wow me (most especially since > many developers would not know how to place a breakpoint in a gettter/setter > for a while after such an improvement). > > Now more type-safe compile-time treatment of properties and event listeners > than that possible with Java, that could be a little more interesting. For > instance having "->" be interpreted as a one-time per-class lookup at > runtime for the corresponding bean property accesser or field with efficient > access thereafter. The type would be that expected based on > accessers/fields found during compilation. Or something to this effect... > > Overall I'm pretty happy with Java generics as well. They're not perfect, > but type erasure rarely causes me issues and while handling primitive type > parameters would be nice, the lack thereof isn't causing me much pain > either. > > Delegates are generally somewhat of a yawn in my book as well, though I see > the point to function pointer like semantics for function programming. > > Closures seem like a good addition, including FCM-like semantics. They're > still not a univerally good addition, though. They bring with them enormous > complexity or enormous limitations -- depending on the proposal. For > instance, BGGA's non-local return semantics are very discordant and > inconsistent with the inner class semantics. It's control structure > features are great for ease of writing and one level of readability, while a > possible bane to any deeper comprehension. You get cool looking stuff like > forEachFoo(...), but it seems likely that many developers will have serious > issues distinguishing what's a language control structure and what's a > library one -- and how to follow/debug such control structures. BGGA also > has a thousand wrinkly corner cases to explain. All that said, BGGA would > also reasonably succinct type-safe expression of software concepts like > LINQ. Also it's exception transparency concepts are long overdue and would > simplify things beyond closures themselves. > > In the end, syntactic sugar bits are okay, but I can't see how everyone can > get so excited about their presence -- or absence. Major features like > closures, particularly those that allow type safety to be maintained over a > broader portion of the software, are grounds for getting excited, but also > often have downsides that have to be considered. More is not always better > when you deal with large groups of developers -- as some may feel the need > to use the craziest, most complex features they can, and produce code that > is intractable to most the organization while others may have serious > difficulty grasping complex language features period. I believe closures > make the cut -- they help more than they hurt, but it is a close thing... > > -- > Jess Holle > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
ReflectPropExample.java
Description: Binary data
