4 ms·
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
by 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 agoYou 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 agoFirstly, 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!