One of these plusses is not like the other.
In Java 3 = 12
11–20 of 55 posts
Re: In Java 3 = 12
#12Oh but it's not an article about how shitty javascript is, so let's just ignore it.
Re: In Java 3 = 12
#13It's evaluates left to right.
(1+2)=3 then concat with string = then concat with 1 and concat with 2.
The optimiser converts these concats to a StringBuilder.
https://docs.oracle.com/javase/specs/jls/se8/html/jls-15.htm...
Second time I've seen something like this on HN.
Re: In Java 3 = 12
#14so does javascript
Re: In Java 3 = 12
#15[deleted]
Re: In Java 3 = 12
#16Things to consider here are:
- operator precedence
- implicit type casting
- how operator+ is defined per each type (e.g: numbers add, strings concatenate)
Re: In Java 3 = 12
#17I suppose that's something every Java programmer should know: How types are automatically converted during "arithmetic" operations. There are some subtleties (like byte+short => int), but it's not too much to remember.
The deeper question is: Was it a wise choice to disallow operator overloading BUT use "+" as a string concatination operator AND convert all values to strings during string concatenation?
I think not, but it's a rather moot point, since that desing decision is not likely to change...
Re: In Java 3 = 12
#18So on mobile you can't see the entire width of that website, but trying to scroll to the left or right changes articles. Absolutely brilliant, why do people think that overriding the scroll on mobile is a good thing is beyond me.
Re: In Java 3 = 12
#191) Left-associativity 2) The price you pay for type coercion. Be thankful Java defines the order of evaluation. Not all languages which coerce specify the order of evaluation.
Yes but that's strange. Java is such a staticaly typed language you would not expect it to do that if you are like me and don't know it very well. While Python is very dynamic, but: >>> print(1 + 2 + "=" + 1 + 2) Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str'
Ruby is like Python, Perl and JavaScript are like Java. Type coercion has little to do with being strongly or weakly typed, dynamically or statically typed, interpreted or compiled, which are orthogonal axis. It's more like syntactic sugar to save a str(), a .to_s or a printf pattern. Maybe the Java implementation just overloads the + operator and converts the types inside it.
Re: In Java 3 = 12
#201) Left-associativity 2) The price you pay for type coercion. Be thankful Java defines the order of evaluation. Not all languages which coerce specify the order of evaluation.
Yes but that's strange. Java is such a staticaly typed language you would not expect it to do that if you are like me and don't know it very well. While Python is very dynamic, but: >>> print(1 + 2 + "=" + 1 + 2) Traceback (most recent call last): File " ", line 1, in TypeError: unsupported operand type(s) for +: 'int' and 'str'
This is possible exactly because Java is statically-typed. Java's type system works over the operands, and does implicit conversions before the expression gets a chance to run. It sees values and does implicit magic from left to right.
Python, on the other hand, does not need to do a typing pass at parse-time. Instead, literals are stored as values, and those values are tagged with their source class. Python's way of doing it means that a + operation is called upon with an integer and a string.
Java might be able to yield the same kind of result as Python if it had operator overloading. It could define Integer's + operator as only taking other Integer values, therein yielding a type error at parse-time.
My own language uses ++ instead of + to distinguish between addition and concatenation, though I've considered some other token since the two are quite similar to each other.