> getting the return type of a method and getting the input parameter names (+ types)
Type information literally doesn't exist at runtime, though. Isn't it kind of ridiculous to compare languages like that?
When you're comparing the relative power of reflection within the language, absolutely not.
But what would you use that information for, given that the language has no types? A JS function has no guarantees of what type a function returns anyway. It's like taking issue with the fact that a car doesn't come equipped with skis.
Re:The melting pot of JavaScript (2017)
by stickfigure on Monday January 07, 2019 @11:42PM
(#18853206)
It's like taking issue with the fact that a car doesn't come equipped with skis.
To draw out that analogy... we live in Greenland. Cars with skis are surprisingly useful.
> Type information literally doesn't exist at runtime, though.
Correct if I'm wrong, not all types get erased in Java. Doesn't type erasure only happen for generics? Say I have a non generic, plain Java class and want to inspect one of it's method's return types at runtime to see if it returns class A or class B. I can do that, right?
Re:The melting pot of JavaScript (2017)
by stickfigure on Monday January 07, 2019 @11:45PM
(#18853215)
Yes, you are correct. There are also a number of circumstances in which you can get generic type info - it isn't erased, for example, if you create a concrete subclass of a generic type.
I was talking about JavaScript. In JavaScript there are no typed functions or arguments, so that information doesn't exist period.
Right, so I guess I'm not understanding your point about why comparing two languages like this is ridiculous. Java has a full blown runtime reflection system (it's "types exist at runtime"). JS doesn't. So Java wins in the reflection category.
Re:The melting pot of JavaScript (2017)
by tracker1 on Tuesday January 08, 2019 @03:43PM
(#18859479)
But in JS, reflection is pretty much not needed... I don't need to use reflection to see if an object has a quack method, or that I call it with the right types... I just call instance.quack() ... It's up to you as the developer to keep your interfaces and composition in line.
It's actually WAY easier than with C# or Java. Since the use-case of reflection itself is largely unnecessary.
Re:The melting pot of JavaScript (2017)
by lopatin on Saturday January 12, 2019 @09:46PM
(#18894719)
Calling a method and seeing what happens is not a substitute for reflection. You can do that in Java too btw.
Re:The melting pot of JavaScript (2017)
by orangeeater on Monday January 07, 2019 @04:31PM
(#18850348)
> Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation.
Ah, that's quite cool.
You can do almost anything with Java reflection, JS really pales in comparison.
Which in some ways is a good thing as you can do a lot more optimizations.
Among hundreds of other things, getting the return type of a method and getting the input parameter names (+ types) in a way that doesn't revolve around literally parsing the functions toString() representation.
Oh, and typeof checking that isn't disgustingly broken.