Lady in Love @Lady@cat.family

@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 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

@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

@wallhackio @Satsuma you can't Object.setPrototypeOf("foo") and have it work, importantly

@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 not QUITE because the this value when calling methods is the original literal not the object-wrapped form

@wallhackio @Satsuma

@wallhackio @Satsuma so what you are thinking of as “numbers and strings” is actually “object-wrapped numbers and strings” which do indeed have the internal slots that you describe

but what is in those internal slots? the original immutable number and string literals

@wallhackio @Satsuma the confusion is that for all of these things Javascript is doing `new Object(…)` behind the scenes, so that

"foo".toString()

is literally

new Object("foo").toString.call("foo");

"foo" itself is not an object, javascript just does a lot of behind-the-scenes object wraps in necessary places to make it work like one in many cases

@aescling @wallhackio @Satsuma yiu mean 1..valueOf()

@wallhackio @Satsuma this is also why you can't do

const foo = "foo";
foo.bar = "baz";

and have it be sensible; but you can do

const foo = new String("foo");
foo.bar = "baz";

without issue

@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()`

@wallhackio @Satsuma honestly thinking everything is an object is imagining javascript to be simpler and more consistent than it actually is

@wallhackio https://open.spotify.com/album/68bZxGAXn6BcPdx26LiLyj?si=-VPevxtPR3qMvpbn8AfZnw

@alyssa @Satsuma @aescling ¿tenés música en español qué podamos escuchar?

@alyssa yo sabía el idioma bastante bien en colegio secondario pero hace pasado mucho tiempo

@Satsuma sace muchas clases de español pero sus profesoras fueron muy malas

@aescling no sabe nada de español pero ella cree qué debería

@alyssa @aescling @Satsuma estoy jugando pokémon leyendas arceus en español y ha snowballed

pero, sí

@coriander @aescling @wallhackio we were debating whether caleb knew the difference between this and someone who listens to metal