Alan Keefer
Posts: 29
Nickname: akeefer
Registered: Feb, 2007
|
|
Re: New Control Structures for Java
|
Posted: Oct 17, 2008 2:18 AM
|
|
@Howard
I think my fundamental problem is that I don't see a good reason to take some obviously functional concepts and techniques and to try to shoehorn them into objects and classes. Some operations are more naturally functional, and sometimes first class functions just make the most sense. So to take something like the map() method or the each() method, then define an interface that contains one function inside it, then devise some syntax and compiler tricks to make it look like you're defining just a function when in reality you're defining a class that defines a single method . . . that just seems like exactly the type overengineered solution that gives Java a bad name. You're going to all this work to make it look like you're passing in a function, so why not just pass in a function already? Why bother with the confusion and overhead of Object Orientation when you don't want it and it just confuses the problem?
If you care about variable capture semantics, I think the closure scoping rules in Java should exactly mimic what you get with an anonymous inner class, i.e. read-only access to final variables. I like keeping the rules simple and consistent. I see no good reason to add in crazy return or exception semantics either (which is one reason the BGGA proposal scares me), and they can have the same rules as if they were on an anonymous inner class.
If you do that, where exactly is the possibility for confusion? Writing userList.map(\u -> u.Name) is pretty hard to screw up. If you start getting really complicated blocks in there, you end up moving them out to a helper function anyway to make the code more readable. I just don't see how simple closures could confuse anyone, unless people insist on things like restricted versus unrestricted closures, crazy return and exception semantics, etc. If they use the same scoping and semantics that people already understand, it's not a problem.
Comparing defaults (like extends Object) to complicated syntax rules (like what you've proposed) isn't really the right comparison. You can always leave off "extends Object." You can always leave off "= null" on a variable declaration that you want to default to null. The problems arise when you have rules that sometimes apply but not always, because then you have to understand those situations, like with if statements or for loops that can leave off curly braces unless they have more than one line underneath them. The type of rules you've proposed are exactly that kind, where they sometimes apply, and you have to know when they apply, so it adds a whole bunch of rules to the language. I'd rather have one, easily-understood feature (a closure is just a function, and everyone understands functions and anonymous-inner-class scoping rules) instead of a whole raft of complicated rules for syntax shortening.
As to arguing that inner classes are better because they have inheritance and fields, that's a total functional-programming anti-pattern. If you're doing something functional you should be using composition, not inheritance, and you should probably be avoiding side effects (like local variable writes) as well. If you have functionality that's so complicated that you need to pass in a full-on object with state and a bunch of methods, go for it; you can still do that. But the whole need for closures is for something lighter-weight and more functional than that, which is exactly the problem space in which state and inheritance is a bad idea. The whole point of using a method like .map() is because you want to make your life simpler; if you need to do something really complicated, there are already plenty of ways to solve that problem. Java scales up in complexity just fine, it just scales down in complexity very poorly.
That's perhaps too long-winded, but the basic point is: there are times where you really do just want a function, not a class.
|
|