Tuesday, 6 July 2010

functional programming and java - no thanks!

If this is a sign of things to come in Java-land I suspect I'll be moving on:

http://stronglytypedblog.blogspot.com/2010/07/lambdas-in-java-preview-part-2.html

Ugly. Very ugly. So ugly in fact, I want to swear. I haven't looked at the strawman proposal yet, and really don't want to, but I suspect there will all kinds of problem with scope.

Functional programming has it's usefulness, it's great for languages like JavaScript for instance, which I think needs it in order to make up for lack of proper OO syntax or semantics.

What would be really useful in Java is autosynthesis of properties. What the hell do I mean by that?

Well any Java programmer knows that they'll end up writing getters and setters for properties, or ignoring them all together and making the instance variables public (I don't!). A useful feature in Java would be a way to reduce the need for getters and setters while retaining binary compatibility.

It's really not hard:

public class Person {
public property String firstname;
public property String lastname;
}

Which can then be accessed in *either* of the following ways:

System.out.println(person.firstname);
System.out.println(person.getFirstname());

And if you really want a getter or setter ... just add it!

public class Person {

public property String firstname;

public property String lastname;

public String getFirstname() {
// Do something funky, return something completely different, or just return the property itself.
return firstname;
}
}

OR

public class Person {

public property String firstname;

public property String lastname;

public String setFirstname(String firstname) {
if (firstname == null){
throw new NullPointerException("firstname cannot be null");
}
this.firstname = firstname;
}

}

That's the kind of thing I want added to Java.

3 comments:

ChrisBartlett said...

Are you aware of Project Lombok?
http://projectlombok.org/

Handy for prototyping.

Chris Brind said...

Hey Chris, thanks for that - looks pretty awesome actually!

You say handy for prototyping, I presume that means you wouldn't use it in a production environment?

ChrisBartlett said...

Although it seems stable enough, I just mean that many people might not like the idea of checking in source that would later be modified by an external jar at compilation time.

You would need to keep the appropriate Lombok jar in source control too, and ensure it was used during the compilation. Otherwise the class file might differ depending on what version of the Lombok jar you use to compile with.

You can get around this with their 'delombok' tool though.
http://projectlombok.org/features/delombok.html

I would check in 'delombok-ed' code which is then indistinguishable from hand written code and can be scrutinized and unit tested without additional processing.