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 -~----------~----~----~----~------~----~------~--~---
