All I’m asking the compiler to do is insert an implicit cast to the destination type to save me having to pollute the meaning of my code with (String) etc all the time. That’s trivial for the compiler to do. It doesn’t have to do any compile time analysis beyond that, so yes, I’m not asking for “full type inference” but just “implicit casting”.
Cas 
wondering how your code looks like, so that you need casts “all the time”.
only thing what could be done in this direction could be something like this:
Object a;
if(a instanceof String)
{
String b = a;//without compile error
}
also the try cast from C# can be helpfull, which casts or returns null if the type dosn’t match.
I think one don’t need any casts anyway, perhaps only for some strange magic deep inside some implementation.
I think casts are fine. I use it to grab my game instance, from almost anywhere. Slick has this “GameState”, but ofcourse I’ve extended it to fit my needs, like grabbing the current map being drawn. The API doesn’t care for that though, so this is what I do to get access:
game = (IngameState) sbg.getState(GAME_STATE.GAME.getID());
Different states, different needs. Since this is part of Slick, I see no slick (;)) way of doing that, without casting. Another example is datagram packets. I use KryoNet, so serialized objects are the packets. To keep it OOP, I have to do a cast though, to know what fields I should be looking for. Else, it’ll just be a byte-array which takes away the entire point of serializing objects to send over the network.
That would indeed be very neat.
[quote=“Danny02,post:62,topic:40839”]
Indeed, for example this is what Kotlin lets you do. The benefit is that you never encounter unpleasant surprises at runtime. The IDE also highlights variables within inner scopes that have been auto-casted to another type.
That’s called type inference, and it already does this with generics. The language guesses, and it’s always correct (it it can’t guess perfectly, it won’t compile). Welcome to the state of the art in compiler technology, circa 1973. I imagine some people still have a problem with this the same way that others did with automatic memory management, sure.
Yes, I’m snarky about it, but we’re arguing about things that have been solved problems for 40 years, and the consequences to real-word productivity over this kind of sloth are quite real.
And like I said earlier…if you don’t know and you need to…it’s just on mouse hover away. Big deal.
Yes of course using mouse hover IDE smartness to know what the type is helps deciphering this sort of thing. But it’s still a bit of an obfuscated syntax if you ask me.
I mean I like to be able to easily read code ‘as-is’, without having to depend on IDE voodoo. For example reading code from the internet or books.
It’s probably not a big deal in practice and perhaps I’ll learn to like it, but to be honest I usually prefer a bit of verbosity but completeness and consistency over brevity by leaving out information and implying stuff. For example one of the reasons I don’t like Groovy is because it seems it goes for brevity for the sake of it, which has the effect of making Groovy seemingly very inconsistent and not that readable at all.
How does this work btw if in this example ‘addActionListener’ accepts different types as arguments? Do you then just need to explicitly note the type as per Spasi’s example?
If it can be inferred based on what you do inside the listener body, it will do so. Otherwise, it will make you give the type explicitly, yes. Java however doesn’t go to heroic lengths to infer it like Haskell (nor does Scala), and tends to make you use explicit typing at the slightest hint of ambiguity.
[quote]Welcome to the state of the art in compiler technology, circa 1973.
[/quote]
Lots of smart things have been thought up by really smart people.
Together with millions of other developers, I’m probably not that smart. There’s a reason that many really old and genius language concepts haven’t really caught on while simple stupid languages like C and Java did become popular.
Thanks sproingie, that was a really clear explanation
Lots of smart things have been thought up by really smart people.
Together with millions of other developers, I’m probably not that smart. There’s a reason that many really old and genius language concepts haven’t really caught on while simple stupid languages like C and Java did become popular.
[/quote]
I don’t understand the calculus behind type inference myself either, but I don’t have to in order to use it. That of course is the whole point of compilers: they do the work so you don’t have to. They’re already running some pretty sophisticated algorithms just to allocate registers, to pick one example out of many. Full global type inference is a knotty problem (in fact it’s equivalent to the halting problem) but local inference has, I think passed from voodoo to common sense, and I don’t think any new language coming out now will gain acceptance if it doesn’t support at least some local type inference.
Well I guess I’ll just have to learn the benefits of these lambdas besides giving you more code brevity.
I just tend to cringe with too much implicitness, but that might be just me not seeing the big picture yet and not having done any real work using these lambda expressions yet
Here’s a nice article on lambdas and what they mean for the JDK libraries and the code we write.
Note that the latest jdk8 lambda-enabled builds already have some API changes compared to the article. For example Block is now called Consumer.
I am not a fan of function pointers, first class functions, or anything similar. For object methods, the exclusive use of interfaces is superior to what other languages do. It would be nice if the language supported interfaces with static functions defined in a different class. “Class” for lack of a better term. The benefit would be for stateless functions where there is no need to create new objects. Comparator objects for example usually doesn’t benefit from having a state.
Maybe syntax like this could work.
Class<Comparator2<String>> c = String.Comparator.class; // No Object created
int i = c.compare("A", "B");
There are benefits, but I don’t like exotic solutions. (Based on unrelated languages.) Time invested in making Java more like super theoretical hypothetical academic languages or a scripting language instead of trying to compete with C, C++, and C# bothers me. (When will structs be added?)
Lambda expressions are only “exotic” hoity-toity ivory tower things because you don’t have any experience with them. I recommend stepping out of your comfort zone and seeing what various languages have done since the 1960’s.
Incidentally, even C++ has lambda now (and unspeakably weird syntax but C++ users are used to that I suppose)
that would make native communication quite a bit easier.
boolean test(T t);
T get();
void accept(T t);
R apply(T t);
void apply(Collector<U> collector, T element);
T operate(T left, T right);
This is not normal Java. I remember reading that the exclusion of a Pair<A, B> class as in STL was deliberate. There is a Point class because it it is preferable to Pair<int, int> because the latter obfuscates meaning. The same was said to apply to methods. Even though you could make a generic Pair, Triple, Etc. or an interface with a generic public void method(A a, B, b) header, people advised others not to. I suspect duck typing will be the next addition because it’s been hyped on C# blogs. Obfuscation is the main problem. The other is that a syntax sugar arms race that makes the language bloated. (Not that there isn’t a need for certain new features.) Syntax should be simple and semantics should be obvious and accurate.
I worry we will see indefinite hacks and new Java 1.X versions. Java suffers from backwards compatibility like most languages. (C++ being most extreme.) It would be interesting if Java 2.X chose to re-implement features with a smaller but more powerful feature set overall. (And new API to take advantage of extra power.)
Q: Why is Java such a manly language?
A: Because it forces everyone to grow a Pair.
Tuple types are useful, but I’m not sure how useful without literal syntax.
As for Java 2.x, I really just don’t see that happening. The only thing likely to break backward compatibility is going to be a whole new language, and I’m afraid that’s likely to be some form of Javascript 
Java might not be perfect, but it is a good language that is verbose enough and (up until now) did not have to have all the bells and whistles. Sadly that has changed. Guess we have to follow every dumb trend just because someone came from a different language and is now complaining that their bells and whistles are missing.
Strange that Java became so widely used even without all this feature bling.
If you want to do functional programming, go grab a functional language. If people do not want to write code, maybe coding is not their thing. Also the compiler should not do your thinking for you. And you should be able to see what the code does WITHOUT the IDE helping.
I guess if my crappy hammer cannot slice and dice and use it as a shovel, it must be a crappy hammer and I am to dumb to see the benefits of said features.
Revisionist history here folks. Most of the big features that have been added to java over the years are all things that would have been there in the first place in an ideal world of infinite engineering time and budget.