hi @Lady i just got rage-baited by some very poor javascript criticism would you also like to be annoyed by it
@wallhackio @Lady she’s playing Leyendas Pokémon: Arceus but i will read it to her if you want
@Lady @Satsuma Here, have a transcription of the most appalling part of the video:
Author: "And why is nearly everything an object? Why is Strings objects? Why are numbers objects? They're just numbers. Like I get that it's for method but does NaN need to be an object?"
[screen shows author using the node.js REPL calling the valueOf method of NaN]
Author: "Why would anyone want to get the value of something that explicitly states it isn't a number?"
[Cut to screenshot of freecodecamp.org's description of JavaScript which claims that "JavaScript is not a class-based object-oriented language".]
Author: "Any many argue that JavaScript isn't object-oriented."
[cut to screenshot of towardsdatascience.com's description of JavaScript which claims that "Nearly everything in JavaScript is an object".]
Author: "Looks pretty-object oriented to me... And why is that functions are also classes? That's what [ES6] classes are for."
@wallhackio @Satsuma honestly thinking everything is an object is imagining javascript to be simpler and more consistent than it actually is
@wallhackio @Satsuma no, strings, numbers, etc in javascript are explicitly not objects, they are literal (immutable) values
this is why `"foo" === String("foo")` but `"foo" !== new String("foo")`; the result of a new expression is always an object, whereas the result of `String("foo")` is a literal string value
cf. the `typeof` operator
the purpose of valueOf is to get the literal value of a wrapped object type, so `"foo" === (new String("foo")).valueOf()`
@Lady @Satsuma okay let me clarify my confusion then. If I have a value of number type I can call Object.getPrototypeOf on that number and get the Number.prototype object.
I can call methods and access properties on the number as well.
In general things we call primitives in JavaScript has property access and is in a prototype chain (although now that I think about it im sure undefined and null don't fit into this).
I was under the impression that values are containers for information that allow property access semantics, and that all values in the language participate in this, and the language makes a very poor decision of overloading the term "object" to simultaneously refer to one of 1) the fundamental container type that (all?) values in JavaScript are 2) non-null types that typeof tells you are "object" 3) instances of ES6 classes
@wallhackio @Lady @Satsuma js has weak typing; what i think is happening is that you are implicitly coercing purrimitives into objects
@aescling @wallhackio @Satsuma not QUITE because the this value when calling methods is the original literal not the object-wrapped form
@Lady @wallhackio @Satsuma yes i am seeing that is how the standard defines both the syntax and underlying opurration
@Lady @wallhackio @Satsuma a.b is defined on all language values a and the associated opurration works on any language value repurresented by a
@aescling @wallhackio @Satsuma yes but ultimately it boils down to a GetValue which calls ToObject on the value and then does a property lookup on the result using the original value as the this value (in case the property uses a getter)
and THEN in the case of a method call does a Call on the result again using the original value as the this value
(so it's actually
Reflect.get(new Object("foo"), "toString", "foo").call("foo")
); i overly simplified before
@aescling @wallhackio @Satsuma javascript is Good(tm) because it doesn’t have weak typing so much as syntactic sugar; it is not simply casting things to objects but rather preserving the original values in a nest of operations which cast only when absolutely necessary
@Lady @wallhackio @Satsuma i’m not even sure i would always call it syntactic sugar; like the example i was talking about earlier (a.b syntactically being defined on all language values) is not really sugar fur eventually casting to object, but rather, syntax fur an opurration that will, eventually, cast to object. which is imo subtly diffurent
@aescling @wallhackio @Satsuma well the more historically correct way of thinking about it is that Javascript has added syntactic molasses for manually doing the operations that it was always doing under the hood, but the even more enlightened understanding is that all of javascript is syntactic sugar for the ecmascript specification language, at which point the difference between “an operation which does a thing” and “sugar for the thing itself” is semantically meaningless
@aescling @wallhackio @Satsuma coffeescript is an alternative syntax for javascript but javascript is the ORIGINAL alternative syntax for javascript
@aescling @wallhackio @Satsuma so
a.b = c.d(e);
is syntactic sugar for
Reflect.set(Object(a), "b", Reflect.apply(Reflect.get(Object(c), "d", c), c, [e]), a);
each step of which converts only as absolutely necessary and does property chain lookup as required
@Lady @wallhackio @Satsuma https://262.ecma-international.org/15.0/index.html#sec-evaluate-property-access-with-expression-key