Completely agree, my hat off to you for speaking frank even though you
obviously realize how unpopular that could make you. I'm rather hoping
Neal Gafter's change will perhaps open up the community a little to
stimuli from outside, for its own sake.
/Casper
On Nov 2, 12:56 pm, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
wrote:
> I'm not trying to set myself up for flaming here, so please read on.
> The reason I started off with this topic is that I see a great deal of
> `we need feature {x} implemented in Java' and then a whole host of
> solutions to the problem and then large debates over them.
>
> Again, not looking for flame wars, but I honestly think that C# is a
> brilliant language, Anders Hejlsberg truely knows what he's doing in
> this realm. There are three points to the C# language that they really
> got right that Java needs to learn from, and why not just take the
> exact same implementation?
>
> 1. Properties: Properties are so freaking simple in C# that it just
> isn't funny any more. Take the following examples of C# properties.
>
> // A traditional property
> private String name;
> public String Name {
> get { return name; }
> set { name = value; }
> }
>
> // This can be simplified since it's such a normal property not
> performing
> // any logic, the compiler will generate the field and accessors
> for the field for us.
> public String Name { get; set; }
>
> // We can then make this a readonly property by applying a set
> accessor.
> public String Name {
> get;
> protected set;
> }
>
> 2. Events: I don't want to elaborate too much here, but they're
> similar to properties syntactically, they simply allow "subscribing/
> unsubscribing" function pointers.
>
> // Declare an event
> public event EventHandler<MyEventArgs> MyEvent;
>
> // Or you can control access tot he event via add, and remove
> notation as is for
> // Properties
> private event EventHandler<MyEventArgs> myEvent;
> public event EventHandler<MyEventArgs> MyEvent {
> add { myEvent += value; }
> remove { myEvent += value; }
> }
>
> // Subscribing a function pointer is very simple also,
> `DoMyEventFired' is a
> // function pointer matching the contract of `void (Object,
> MyEventArgs)'
> MyEvent += new EventHandler<MyEventArgs>(DoMyEventFired);
> // Unsubscribing is the same, just with -=
> MyEvent -= new EventHandler<MyEventArgs>(DoMyEventFired);
>
> 3. We all know that generics were not really implemented that well in
> Java, but simply take a look at how they were solved in C#, we don't
> have the problems of type erasure, they're also easier to understand.
>
> I love Java, but we need the above, if we don't get the above we're
> going to fall behind. There's many more that C# has like type
> inference. Now with C# 3.0 and 3.5 we're starting to really fall
> behind, take the following:
>
> 1. Use of the keyword `var' on the left hand side of a scoped field
> declaration the compiler knows what the type is based on the right
> hand side.
>
> // In the following "myComplex" is still statically typed, the
> beauty of it is in the
> // compiler working out the type for us through implicit type
> inference, var is inferred
> // from the right hand side.
> var myComplex = new Dictionary<String, List<String>>();
>
> // thus we can use this as:
> foreach (var val in myComplex.entrySet()) {
> // val is inferred to be of type `List<String>', so the
> following will throw a compiler error
> foreach (String str in val) {
> }
> }
>
> 2. Extension methods, please don't implement the way suggested
> athttp://tech.puredanger.com/java7/, take a look at this instead. Please
> not that because `you' get to control the behavior it makes it easier
> to understand what's going on.
>
> // Basically we need to explicitly declare an extension method to
> be used by
> // declaring a static class with a static method taking the `this'
> keyword as a param.
> public static class MyNumberExtension {
> public static double Pow(this double x, double y) {
> return Math.Pow(x, y);
> }
> }
>
> // With this the following two are equal
> double resStd = Math.Pow(2, 2);
> double resExt = 2.Pow(2);
>
> There are many more `features' of C# that I think we can learn from in
> Java. Too many people I talk to have the attitude of "why look at C# I
> never want to write programs for windows", well, I don't want to write
> programs for windows either, but if they're standing on our shoulders
> for the language perspective we need to have a rugby match with them
> and actually compete.
>
> Please don't dismiss this post as trying to start a flame war, I
> really think Java can become so much more than it is. These abilities
> make the component model in C# soooo easy to program against, you end
> up with unexpected things like visual inheritance and a greater
> flexibility for annotating that is accessible via reflection at
> runtime making a vendor writers job as simplistic as it needs to be.
>
> Please also forgive me for the length of this post.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
