I wonder if they will ever revamp the actual text portion of Java. :persecutioncomplex:
I would love something like this…
public void doSomething(float x, y, int sx, sy) {
}
Well, having more than 3-4 parameters is a sign of code-smell, so why would be lower the barrier 
Because I don’t want to type float 5 times 
nor double 3
there is foo(long arg, String… otherArgs).
I think you should re-read @Riven’s answer! ;D
Still, as much as I dislike the enhancement you’re suggesting, I think I prefer it to local variable type inference.
var list = new ArrayList<String>();
Put the two together and we could have -
public void doSomething(var x, y, sx, sy) {}
Joy! TL;DR what we have could be a lot worse - I’d rather have verbose and legible.
In the Java mindset you can’t tell if the missing type is an error…so that will never happen.
I still like my way better.
Usually using var whatever is redundant because in times of building an object, you could just do… (for example)
[i]function[/i](new ArrayList<String>().add("abc").add("def"));
That will not work because the compiler does not know what type var would be if you use it as method parameter.
It works just for local variables, and only if it is clear what type it is. E.g. var x = null; or var x; would not be possible at all.
@topic
Never had this idea nor the need to do it that way, but it looks kind unfamiliar for me… dunno why
This fluent interface style would already be possible today in your concrete example, had the ArrayList.add() method been designed to return the ArrayList instead of whether the element was added to the list via a boolean.
You can perfectly design a new custom ArrayList that is capable of doing what you want:
import java.util.ArrayList;
public class FluentStyleArrayList<T> extends ArrayList<T> {
public FluentStyleArrayList<T> addFluent(T element) {
add(element);
return this;
}
}
...
new FluentStyleArrayList<String>().addFluent("abc").addFluent("def")
I know. I was being sarcastic! ;D
Oh, sorry… I see - should the “Joy!” indicate this? (Didn’t get it though, got totally over my head, maybe because of my non-native-speaker-ness ;)) - so at least that is cleared up now
But yeah, I’m totally with you, its better to have it clear.
This.
Source code should be easily and quickly read and understood by humans.
Anytime a language adds a new feature there are ideally a number of points that should be considered, including (but far from limited to):
- If it consumes syntax design space…is it worthwhile?
- Does it fit the overall design space of the language? Feature “A” can be a brilliant idea in language “B”, but terrible for language “C”.
Ignoring basic like this yield languages like Perl and C++. C++ seems to spend a fair amount of it’s time attempting to correct past mistakes.
And it doesn’t help that a fair number of people working on compilers these days have lost touch with what they’re really suppose to be doing. What every compiler writer should know about programmers
Wait…
import java.util.ArrayList;
public class FluentStyleArrayList<T> extends ArrayList<T> {
public FluentStyleArrayList<T> add(T element) {
super.add(element);
return this;
}
}
...
new FluentStyleArrayList<String>().add("abc").add("def")
I have not a clue if this works… never did this before.
I’m not a fan of fluent style stuff myself, though before my coffee I couldn’t rant enough in a logical way to say exactly why yet…
Cas
Because it hides return-type changes. In real-world ‘fluent’ classes, not every method will return ‘this’.
Ah yes, that was it. And it looks daft.
Cas
You must really hate Java 8 then?! 
Have to say I really am a fan of this if done well. To me it’s the opposite issue to above - reducing verbosity increasing legibility. And it’s not like you have to use it anyway.
Mind you, the fluent stuff (or any method call) on the end of a constructor does look daft. To each his own. 