3 ms·

Normally, declaring a variable offers type safety. var matches anything and thus it's never a compile-time error. If someone accidentally changes the return typ

Normally, declaring a variable offers type safety. var matches anything and thus it's never a compile-time error. If someone accidentally changes the return type of getAddresses from Map to List, there is no compile-time error. There is nothing to check the return type against except Object in this case because Tuple.of takes Objects. final var addressMap = getAddresses(); final Tuple args = Tuple.of("a", 200L, x); So you may as well inline the method call and give up on any type checking. Another example: final long limit = getLimit(); for (var i = 0; i < limit; i++) {} The wrapping behavior is determined by whether there is an L (or lowercase, l) after the 0. If limit happens to be greater than Integer.MAX_VALUE, that L is the difference between an infinite loop and a well-behaved routine. Some junior programmer could easily remove the L accidentally. And you wouldn't run into the bug until limit gets big enough. Which could happen at runtime in production. All because you wanted to save one character by using var instead of long. This is just what I could think of off the top of my head. I'm sure there are other examples. You are absolutely giving up some compile-time sanity checks with var. If it's just some throwaway script, then fine. But if so why use Java in the first place?

kaba0 3y ago
I’m sorry, but you gravely misunderstand type inference. Sure, there is no compile-error if all you have is a single assignment, why would there be? But that’s a completely useless code. Here is a real example: var list = getSomeFancyLongAssNestedGenericTypedList(); list.append(new HashMap<…>()); If I change the return type of that function to something that doesn’t have a compatible append method, your method will fail. In fact, you implicitly encode all its usage in that var, so it will be maximally safe, while not being more restrictive than needed (e.g. changing to another object that has append may be fine). Also, var is not a must-use, there are useful cases where it gives more clear code and the type is not important (say, when the right side is a constructor call), and there are cases where you really should be annotating your types. But it will be type safe either way.
- iraqmtpizza 3y ago
  Why would there be? I just showed you. Tuple accepts varargs of Object. You want a type check before you erase the argument's type to Object. Also, it's common practice to use local variables rather than inlining, just for readability. This is not some contrived example--this is an actual API that's in use by companies now. Sure, you might append to the list. But in the world of increasing immutability, more likely the return value of getAddresses would be immutable. You don't want to rely on "well hopefully there's a method call that catches the error before it goes into the args list." What did I gravely misunderstand? And if I gravely misunderstood it, then why can't you point out what's wrong with both of my examples instead of running as fast as possible to your own toy example? I'm actually laughing at your totally shameless pivot. >maximally safe You don't know the definition of maximum. Maximum means there exist no levels which exceed it. You have amnesia about the type checks that I just demonstrated which do not occur with var that would have prevented the runtime problems I just explained. If your argument is that, meh, var is "good enough" type checking, then make that argument. Don't pretend like you can't read basic Java code.
  - kaba0 3y ago
    You gave a completely unrealistic example, no one is passing around Object varargs. In the off chance, just specify the type.. I gave a more realistic example where you actually make use of your objects
    - iraqmtpizza 3y ago
      Firstly, I gave two examples. Your argument to the first one is "nuh-uh" (summarized). Your argument to the second one is nonexistent. Secondly, it's not unrealistic. It's not even realistic. It's real. R-E-A-L real. It's in production systems right now, as I said. Modern startups. If you think you can design it better, by all means. "Put up or shut up" is the phrase, I think. Thirdly, any time you have an API that accepts a supertype of the instance in question, this will happen. Run away and hide from the truth. Or man up and admit you oversold your incorrect theory of var. Fourthly, you didn't even address the readability issue. Which of course you wouldn't because... var. Like literally VAR. lol. Fifthly, you still haven't come up with an answer as to what I misunderstood, specifically. Sad!

kaba0 3y ago

I’m sorry, but you gravely misunderstand type inference. Sure, there is no compile-error if all you have is a single assignment, why would there be? But that’s a completely useless code. Here is a real example: var list = getSomeFancyLongAssNestedGenericTypedList(); list.append(new HashMap<…>()); If I change the return type of that function to something that doesn’t have a compatible append method, your method will fail. In fact, you implicitly encode all its usage in that var, so it will be maximally safe, while not being more restrictive than needed (e.g. changing to another object that has append may be fine). Also, var is not a must-use, there are useful cases where it gives more clear code and the type is not important (say, when the right side is a constructor call), and there are cases where you really should be annotating your types. But it will be type safe either way.

iraqmtpizza 3y ago
Why would there be? I just showed you. Tuple accepts varargs of Object. You want a type check before you erase the argument's type to Object. Also, it's common practice to use local variables rather than inlining, just for readability. This is not some contrived example--this is an actual API that's in use by companies now. Sure, you might append to the list. But in the world of increasing immutability, more likely the return value of getAddresses would be immutable. You don't want to rely on "well hopefully there's a method call that catches the error before it goes into the args list." What did I gravely misunderstand? And if I gravely misunderstood it, then why can't you point out what's wrong with both of my examples instead of running as fast as possible to your own toy example? I'm actually laughing at your totally shameless pivot. >maximally safe You don't know the definition of maximum. Maximum means there exist no levels which exceed it. You have amnesia about the type checks that I just demonstrated which do not occur with var that would have prevented the runtime problems I just explained. If your argument is that, meh, var is "good enough" type checking, then make that argument. Don't pretend like you can't read basic Java code.
- kaba0 3y ago
  You gave a completely unrealistic example, no one is passing around Object varargs. In the off chance, just specify the type.. I gave a more realistic example where you actually make use of your objects
  - iraqmtpizza 3y ago
    Firstly, I gave two examples. Your argument to the first one is "nuh-uh" (summarized). Your argument to the second one is nonexistent. Secondly, it's not unrealistic. It's not even realistic. It's real. R-E-A-L real. It's in production systems right now, as I said. Modern startups. If you think you can design it better, by all means. "Put up or shut up" is the phrase, I think. Thirdly, any time you have an API that accepts a supertype of the instance in question, this will happen. Run away and hide from the truth. Or man up and admit you oversold your incorrect theory of var. Fourthly, you didn't even address the readability issue. Which of course you wouldn't because... var. Like literally VAR. lol. Fifthly, you still haven't come up with an answer as to what I misunderstood, specifically. Sad!