Programing Language Jargon: Reflection
Ok, let me give a deep dive of a concrete example why the so-called reflection is wrong think. This, is a example of reflection, in js, from wikip. Best illustration.
// Without reflection const foo = new Foo(); foo.hello(); // With reflection const foo = Reflect.construct(Foo); const hello = Reflect.get(foo, "hello"); Reflect.apply(hello, foo, ); // With eval eval("new Foo().hello()");
- you see those Reflect words? that's a builtin object Reflect, or, rather, it's a builtin namespace.
- now, what wp is trying to show, is that the reflection version, are able to generate/construct a object, at run time.
- therefore, showing the 'reflection' capability.
- btw, the third example shows eval, which does the same, but very inefficient way and not manipulatible.
- now, let me explain, why, the 2nd and 3rd example it used to show reflection, has nothing to do with any concept of introspection at all, and or, nothing to do with getting type info at all.
- the 3rd example, using eval, is self explanatory.
- it has nothing to do with introspection or getting type of things.
- now, the 2nd example, what it's doing, the Reflect keyword there and its methods such as .construct, and .get, and .apply, are basically functional programing features.
- for example, the Reflect.construct(Foo), is simply a functional syntax for operator new in 'new Foo()'.
- nothing about introspection nor getting types.
- now, the Reflect.get(foo,'hello'), is again, a functional syntax, for the operator syntax of foo.hello.
- basically, a function form of getting a object's property.
- in this case, the value of the property hellow, is a function.
- similarly, the Reflect.apply(...), is just a functional syntax of f().
- so, they are nothing whatsoever, to do with concept of introspection nor getting types.
- they are, at least in this js case, simply functional syntax instead of the operators or literal syntax to do the same thing.
- that's my thoughts.
No let reflection taint your brain
- Just scan'd golang's reflect package doc. Makes sense. Https://pkg.go.dev/reflect .
- It basically allows u to return the user defined type, aka compound types. Mostly struct and array.
- It is part of the core or part of basic golang. Written in C or so. E.g. It's not something user can create sans modifying golang.
- E.g. Given a struct, it's not possible to list its fields, i think, sans the package.
- Or, the types of a array. (is it array of int, or string, etc).
- No direct way.
- Yeah. So, this kinda capabilities or need, do not arise with dynamic langs or scripting langs or higher level langs or function langs. At least usually.
- They are typically already there.
- Just typing out my thoughts.
- For example, say, array of int, or array of str. But in elisp, js, wl, bash, powershell, array can have mixed elements. So, does not apply.
- Python, php, too.
- Now for struct, first of all, many of these lang don't have struct.
- Not in js, perl, wl. I don't think in powershell, python, bash.
- It exist in elisp though. I never used it. It also exist in scheme lisp.
- So, if we go back to the question, what's a actual, concrete, example, of needing so-called reflection. The answer is, it never happens in js, python, elisp, wl, php, perl, bash, powershell.
- Whatever u needed to do, can be done.
- Just in c, golang, java, this problem arise.
- So, again, my opinion and a stance, that reflection idea, is a abomination, in comp langs.
- Don't let it taint ur brain.
- It's a concept from bad langs, or, certain class of lacks, that created this concept, but is not a general concept in programing langs.
- Do not let it taint ur brain, in thinking reflection is a gen purpose idea, and then apply it in a wrong way, forcing it into langs that doesn't need it, such as js perl python ruby elisp wl, powershell, etc, mostly all scripting or dynamic or functional langs.
- The situation, is similar to , how 'patterns' idea arise and became a wild fire eating all programing communities, but in fact, it's just c java c++ etc oop langs that need it.