I would say that reflection in JS is terrible compared to .NET. You can only just barely figure out what is in an object, but it's a hell of a time figuring out what any of those things can do. I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

▲

no_wizard 2 days ago | parent | next [-]

>You can only just barely figure out what is in an object

There's a couple really well documented and understood ways of doing this in the language. I'm not sure what you're specifically referencing without more information.

>I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

Is this anymore different than .NET deriving everything from a base `System.Object`[0] type?

Also, what is missing in JS reflection wise that you can't do that would make sense for its environment? (namely, this excludes compile time reflection stuff I know .NET can do, it wouldn't make sense for a scripting language as it currently is)

[0]: https://learn.microsoft.com/en-us/dotnet/api/system.object?v...

▲

moron4hire 2 days ago | parent [-]

In JavaScript, one can tell if an object has a method by iterating over the object keys and seeing if the value is `instanceof Function`.

But that actually tells you very little. You might be able to tell that it takes a certain number of parameters, if you are running on a system that implements Function.prototype.length. But you will have no way of telling what the arguments to those parameters should be, or even what they were even named. There's no way to tell if the function is a method that needs to be `.call()`ed with a value for "this", or if it's just a function that happens to live in an object literal, or if it's actually a class constructor that must be called with `new`! And there is certainly no way to tell whether the function returns a value, say nothing about the type of value it returns.

With .NET reflection, I can do ask those things I lament missing in JS, and guarantee the type safeness of it.

▲

matheusmoreira 2 days ago | parent [-]

Isn't this just a fundamental limitation of dynamic typing?

	▲	moron4hire 2 days ago \| parent [-]
		Most of it is not. Most of the data necessary to support reflection should be available to the runtime or else it wouldn't be able to operate. The runtime is parsing the syntax of the function, it should be able to tell if all exit conditions have a return of any kind. It should be able to tell me at least the names of the parameters. It should know if a function is bound to a "this", or of it's a constructor. It just doesn't give any way to tell me.

▲

naasking a day ago | parent | prev | next [-]

> I wouldn't so much as call what JS does "reflection" any more than "making objects out of poorly implemented hashmaps."

I used "reflection" because that's how it's abstracted in popular statically typed languages. My point was that JS has abstractions and idioms that eliminate some of the need for design patterns like, factory, decorator, strategy, etc., and some of the reasons are because JS's core objects are basically just fancy hashmaps.

▲

actionfromafar 2 days ago | parent | prev [-]

"Javascript" === "Chaotic neutral lisp"

▲

socalgal2 2 days ago | parent | next [-]

lisp to me is (1) the language itself is a lists of lists (2) defmacro lets you manipulate those lists of list at compile time. JS doesn't this do either of these at all AFAICT and so is absolutely nothing like lisp.

Most lisp programs are about writing DSLs using defmacro.

What's the similarity to lisp except that both are programming languages?

	▲	actionfromafar 2 days ago \| parent [-]
		Let me ask you instead, do you consider there to exist any Lisp which has no compiler?

▲

moron4hire 2 days ago | parent | prev [-]

Yeah, I don't like the comparisons of JS to Lisp, because I think they mostly center on the existance of the map and filter methods of Array. To me, that's just not what Lisp is about. C# has map/filter/etc, and we don't say C# is-a Lisp.

And there are many other such features that were once unique/unique-ish to Lisp, that were major selling points for using Lisp at the time, but are now pretty common across a very diverse set of languages. Garbage collection being one. Higher order functions being another.

Lisp's big idea that stuck to being unique to Lisp is homoiconicity. It's the one thing that continues to be valuable enough to warrant using Lisp, despite everything else that has been stolen and copied.

Of course, not that I ever used Common Lisp, and not that I use Racket anymore. I enjoyed the hell out of programming in Racket. Up until the point I needed to access a database. Man, who's got time for that Jankasarous Rex? But I really would love a homoiconic language for the .NET CLR. That would be pretty sweet.

	▲	actionfromafar 2 days ago \| parent [-]
		Well put.