Search |
||
Yet Another Closures ProposalPosted by alexanderschunk on January 17, 2008 at 9:47 AM PST
First: Getting rid of =>Basically, when i read all the proposals, comments and pros and cons on closures in Java the first thing i would get rid of is the obviously redundant => declaration. So in case of block statements the following would be allowed:
{
int x = 0;
int y = 3;
int sum:= x+ y;
}
As i understood it right, => has at least two meanings. It means return for functions and := or = in the other case. Replace => by := for assignmentsI would use := for assignments rather than => simply because := is more naturial to mathematicians and logicians and is usually used to describe an assignment in math and logics. This could be used as outlined above:
{
int x = 4;
int y = 3;
int z = 3;
int sum:=x+y+z; //assignment
}
Use a function keyword instead of {int, int => int} syntaxFor the function declaration, i would suggest to use a keyword rather than a symbol. Why not invent a function keyword that has a similar meaning like => i.g.:
public int function add(int x, int y){
return x + y;
}
In the other case, i would use := instad of => because the arrow direction implies to read it left to right rather than right to left and there is no <= to represant the invert direction. Use a block keyword to declare block statementsRather than just simply type closures i would invent a block keyword that defines a block of anonymous statements:
//only valid for anonymous block statements, not be used in loops
//itereations
block{
int x = 3;
int y = 4;
}
So with these language features you could write a simple to read Java code that is clear and understandable by everyone:
class MyClass{
//declare a function type
public int function add(int x, int y){
return x + y;
}
public int function sub(int x, int y){
return x - y;
}
public void function(List»
Related Topics >>
Open JDK Comments
Comments are listed in date ascending order (oldest first)
Submitted by ewin on Sat, 2008-01-19 01:22.
Basically, when i read all the proposals, comments and pros and cons on closures in Java the first thing i would get rid of is the obviously redundant => declaration.
Wrong approach. The right one would be to get rid of all the closure fanboyz.
Submitted by ricky_clarkson on Sat, 2008-01-19 05:07.
What you showed in your last comment is a different syntax for a static method, and not a closure.
I suggest you spend some time reading the Wikipedia article about closures, and trying them out in various languages.
Submitted by ricky_clarkson on Fri, 2008-01-18 06:25.
I'm having difficulty seeing any part of this as a closure.
Please translate this to your proposal:
public static void main(String[] args)
{
. . int y=5; . . {int => int} addY={int x => x+y}; . . System.out.println(addY.invoke(2)); . . y=10; . . System.out.println(addY.invoke(2)); }
Submitted by brantboehmann on Thu, 2008-01-17 12:03.
I like this syntax much better. It's actually readable. If I wanted more symbols in language, I'd use Perl.
Submitted by alexanderschunk on Fri, 2008-01-18 06:55.
Actually its not really a proposal. Its just some suggestions to integrate closures into Java.
And using => for functions is not the way i want to programm. I prefer:
public static void main(String[] args){
int y = 5;
int x = 4;
int res = int function add(x, y);
System.out.println("result: " + res);
}
Submitted by ricky_clarkson on Fri, 2008-01-18 12:54.
Where in int res=int function add(x, y) is it made known to the compiler that res involves +?
If I change x and y after int res=int function add(x, y) will the value that res returns change?
Submitted by alexanderschunk on Fri, 2008-01-18 13:43.
The add function would have been declared prior using it like a normal method. You could do it as follows:
public int function add(int x, int y){ return x + y; }
public static void main(String[] args){
int x = 4, y = 4;
int res = add(4, 4);
}
Submitted by aehrenr on Sat, 2008-01-19 06:00.
Very good proposal for a good closure syntax. I like it.
Submitted by i30817 on Sat, 2008-01-19 07:59.
why function as a keyword. Is it a reserved name? I'd like something more definitve, like oh, closure.
Submitted by cowwoc on Sat, 2008-01-19 19:01.
This is by far the cleanest Closures proposal I've read so far. I'm still not sure we should add Closures to Java but this proposal makes me give it more serious consideration.
A prototype of this syntax would go a long way in convincing me (and others) that Closures are a good thing.
Submitted by stefan_schulz on Sun, 2008-01-20 02:29.
This proposal is so clean, it does not even propose closures. Is this posting meant as a parody?
Submitted by mystermask on Sun, 2008-01-20 05:07.
*uah*
What's next? The DWIM* operator? Why are people so obsessed to get his/her own favorite language construct into Java? If you want closures, use a language that has clean support for it (not just as an ugly afterthought). This: "How can we add more (junk) to Java instead of fix already known problems" is a good sign that Java is on the way to become the COBOL of the 21st century. Instead of adding complexity that make things simpler in some situation but more complicated overall, start reducing complexity! Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. -- Antoine de Saint-Exupery Let's not forget that Java once started and was successful exactly because of that attitude! -- *) the "Do what I mean" Operator is still missing from Java
Submitted by voidmain on Sun, 2008-01-20 07:40.
Adding keywords is necessarily difficult and makes backwards compatibility a challenge. Recall in JDK 1.5 the addition of the enum keyword was somewhat difficult for existing code. I doubt adding two keywords will be considered, but good luck with the proposal.
Submitted by voidmain on Sun, 2008-01-20 07:52.
One other thing I noticed as I read the second time... Where are the function variables and how do you invoke closures passed as method arguments? Classic examples:
public void doSomething(int y, &int closure()) {
return i + closure();
}
// Inline
doSomething(2, {return 3;}); // 5
// Variable
&int a() = {return 4;};
doSomething(1, &a); // 5
Both of these are really the benefits of closures. I'm not sure what your idea is providing to be honest.
Submitted by voidmain on Sun, 2008-01-20 07:54.
Haha. Look liks the ampersand symbol followed by the keyword int produces the integral symbol. So, mentally replace &int with:
& int
Submitted by j0ke on Thu, 2008-01-17 12:46.
i like this propsal btw ... i hate => shits they are SOOO rubish bla.
Submitted by alexanderschunk on Thu, 2008-01-17 11:02.
Note: The list function sample should be run as follows:
public void function addItems(List intList){
for(int i =0;i < 10; i++){
intList.add(i);
}
}
Submitted by alexanderschunk on Thu, 2008-01-17 11:04.
public void function addList(List intList){
for(int i =0; i < 10; i++){
intList.add(i);
}
}
Puh. Hard to get things right
|
||
|
|