Sam Pullara has some interesting ideas on changes he would like to see to Java.
Auto-casting
To reduce redundancy in the code I will introduce Auto-casting. What this does is that if an object could be cast in place to satisfy a constraint then the compiler would do that. It will fail if the auto cast is ambiguous or if it would fail if the programmer put the cast in explicitly.
Map p = new HashMap();
p.put(”test”, “test”);
String s = p.get(”test”);
I would like to dynamically do this stuff though. As in:
p = new HashMap();
I also think that having native syntax for common structures fits my liking. Everything in Java is via libraries. For this reason I like the native support for lists and maps in Groovy ([1, 2], and [name: value, name: value]), as well as the enhanced GStrings. We use strings ALL THE DAMN TIME. Let’s make them easier to work with!
Using a factory like new method instead of an operator.
StringBuffer sb = StringBuffer.new();
This idea is fine. I don’t mind keeping new Foo() as sugar too. What I *do* want to see though, is the ability to override things so what is returned may be another object. This means that new can be a real factory that returns a subclass under some circumstances. Many languages (like ObjC allow this).
Reflective invocation operator to allow objects to have shapes without explicit interfaces.
Object s = “test”;
s = s->trim();
I have one reason why this shouldn’t be allowed. For copying and pasting the code. the > needs to be escaped! ;)
Closure-like (lite) anonymous inner classes
If an anonymous inner class created from an interface has only one method, allow that method to be implemented without signature. Name any arguments with the lowered classname plus a number if there is more than one or allow them to name the parameters in the new expression:
Runnable r = Runnable.new() { System.out.println(”ran method”); }
FilenameFilter ff = FilenameFilter.new() { return string.endsWith(”.gif”); }
FilenameFilter ff = FilenameFilter.new(File dir, String filename) { return filename.endsWith(”.gif”); }
I would really love full closure support. Talk to the C# guys, and they will tell you how much they love their delegates. Talk to Ruby/Groovy guys and they love their closures (don’t talk to the lisp/smalltalk guys! ;).
I do dissagree on Sam’s point that “What I really want is just a slightly better Java, not a Java-ized Ruby variant”.
I want more than that. I like the Java platform, but I want more options, language wise, on top of it. Different tasks deserve different tools in the toolbox. Although I sometimes want Groovy to be more like Java, I often finding myself thinking more like James Gosling. Why not go the other way, and innovate MORE in this language. Java isn’t going to change that quickly due to the JCP and the desire for backwards compatibility. With Groovy, and other languages, there is no backwards compatibility so new things can be tried. Java is in the toolbox. We can use it. Now let’s fill up that toolbox!
October 4th, 2004 at 11:25 pm
What you are asking for already exists. Just not in Java. You’ve mentioned Smalltalk in your post already though, so there is no point in me mentioning it a second time.
October 5th, 2004 at 5:12 am
“No need for type inference with strong dynamic untyped variables in Smalltalk.”
No need for them in Ruby or Groovy either though. I think Dion is saying he wants Groovy to be groovier. Ruby is more dynamic than Groovy – you can add methods to existing classes, or subclass an individual instance. Maybe that would be a good start.
irb(main):001:0> p = {}
=> {}
irb(main):002:0> p["test"] = “value”
=> “value”
irb(main):003:0> s = p["test"]
=> “value”
irb(main):004:0> double = [1,2,3,4,5].map {|num| num * 2}
=> [2, 4, 6, 8, 10]
irb(main):005:0>
If you prefer Smalltalk method names:
irb(main):001:0> double = [1,2,3,4,5].collect {|num| num * 2}
=> [2, 4, 6, 8, 10]