Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-31 05:10:57 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Userland/Libraries/LibJS/Runtime/GlobalEnvironment.h

59 lines
2.6 KiB
C
Raw Normal View History

LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
/*
* Copyright (c) 2021, Andreas Kling <kling@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#pragma once
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
#include <LibJS/Runtime/Environment.h>
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
namespace JS {
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
class GlobalEnvironment final : public Environment {
JS_ENVIRONMENT(GlobalEnvironment, Environment);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
public:
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
GlobalEnvironment(GlobalObject&, Object& this_value);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
virtual Optional<Variable> get_from_environment(FlyString const&) const override;
LibJS: Make Environment::put_into_environment() return a success bool This code is non-conforming and will eventually get cleaned out once we implement proper variable bindings. However, this will aid us in improving other parts of the code right now.
2021-07-02 00:14:38 +02:00
virtual bool put_into_environment(FlyString const&, Variable) override;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
virtual bool delete_from_environment(FlyString const&) override;
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
virtual bool has_this_binding() const final { return true; }
virtual Value get_this_binding(GlobalObject&) const final;
LibJS: Start implementing spec-compliant variable bindings This patch adds the concept of variable bindings to the various environment record classes. The bindings are not yet hooked up to anything, this is just fleshing out all the operations. Most of this is following the spec exactly, but in a few cases we are missing the requisite abstract operations to do the exact right thing. I've added FIXME's in those cases where I noticed it.
2021-06-23 12:26:37 +02:00
virtual bool has_binding(FlyString const& name) const override;
virtual void create_mutable_binding(GlobalObject&, FlyString const& name, bool can_be_deleted) override;
virtual void create_immutable_binding(GlobalObject&, FlyString const& name, bool strict) override;
virtual void initialize_binding(GlobalObject&, FlyString const& name, Value) override;
virtual void set_mutable_binding(GlobalObject&, FlyString const& name, Value, bool strict) override;
virtual Value get_binding_value(GlobalObject&, FlyString const& name, bool strict) override;
virtual bool delete_binding(GlobalObject&, FlyString const& name) override;
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
ObjectEnvironment& object_record() { return *m_object_record; }
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
Object& global_this_value() { return *m_global_this_value; }
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
DeclarativeEnvironment& declarative_record() { return *m_declarative_record; }
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
LibJS: Start implementing spec-compliant variable bindings This patch adds the concept of variable bindings to the various environment record classes. The bindings are not yet hooked up to anything, this is just fleshing out all the operations. Most of this is following the spec exactly, but in a few cases we are missing the requisite abstract operations to do the exact right thing. I've added FIXME's in those cases where I noticed it.
2021-06-23 12:26:37 +02:00
bool has_var_declaration(FlyString const& name) const;
bool has_lexical_declaration(FlyString const& name) const;
bool has_restricted_global_property(FlyString const& name) const;
bool can_declare_global_var(FlyString const& name) const;
bool can_declare_global_function(FlyString const& name) const;
void create_global_var_binding(FlyString const& name, bool can_be_deleted);
void create_global_function_binding(FlyString const& name, Value, bool can_be_deleted);
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
private:
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
virtual bool is_global_environment() const override { return true; }
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
virtual void visit_edges(Visitor&) override;
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
ObjectEnvironment* m_object_record { nullptr }; // [[ObjectRecord]]
Object* m_global_this_value { nullptr }; // [[GlobalThisValue]]
DeclarativeEnvironment* m_declarative_record { nullptr }; // [[DeclarativeRecord]]
Vector<FlyString> m_var_names; // [[VarNames]]
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
};
template<>
LibJS: Drop "Record" suffix from all the *Environment record classes "Records" in the spec are basically C++ classes, so let's drop this mouthful of a suffix.
2021-07-01 12:24:46 +02:00
inline bool Environment::fast_is<GlobalEnvironment>() const { return is_global_environment(); }
LibJS: Add [[GlobalThisValue]] internal slot to GlobalEnvironment Instead of hardcoding the environment's global object as the return value of GlobalEnvironment::global_this_value(), it now stores an Object reference which is passed to the constructor for this purpose. From the spec (https://tc39.es/ecma262/#sec-global-environment-records): [[GlobalThisValue]] | Object | The value returned by this in global scope. Hosts may provide any ECMAScript Object value.
2021-09-11 19:58:27 +01:00
LibJS: Begin implementing GlobalEnvironmentRecord These represent the outermost scope in the environment record hierarchy. The spec says they should be a "composite" of two things: - An ObjectEnvironmentRecord wrapping the global object - A DeclarativeEnvironmentRecord for other declarations It's not yet clear to me how this should work, so this patch only implements the first part, an object record wrapping the global object.
2021-06-22 17:16:08 +02:00
}
Reference in a new issue Copy permalink