summaryrefslogtreecommitdiff
path: root/Userland/Libraries/LibJS/Runtime/Intrinsics.cpp
AgeCommit message (Collapse)Author
2022-08-28LibJS: Move construction of GlobalObject native functions to IntrinsicsLinus Groh
This will later allow global objects not inheriting from the regular JS::GlobalObject to pull in these functions without having to implement them from scratch. The primary use case here is, again, a wrapper-less HTML::Window in LibWeb :^) Allocating these upfront now allows us to get rid of two hacks: - The GlobalObject assigning Intrinsics private members after finishing its initialization - The GlobalObject defining the parseInt and parseFloat properties of the NumberConstructor object, as they are supposed to be identical with the global functions of the same name
2022-08-28LibJS: Move ConsoleObject construction from GlobalObject to IntrinsicsLinus Groh
This will allow us to move the underlying console from GlobalObject to ConsoleObject without still having to do a 'console' property lookup on the GlobalObject.
2022-08-27LibJS: Move intrinsics to the realmLinus Groh
Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)