Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-11-03 23:00:58 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/Object.cpp

829 lines
31 KiB
C++
Raw Normal View History

LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
/*
* Copyright (c) 2020, Andreas Kling <kling@serenityos.org>
* All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions are met:
*
* 1. Redistributions of source code must retain the above copyright notice, this
* list of conditions and the following disclaimer.
*
* 2. Redistributions in binary form must reproduce the above copyright notice,
* this list of conditions and the following disclaimer in the documentation
* and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
* AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
* SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
* CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
* OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
#include <AK/String.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Heap/Heap.h>
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
#include <LibJS/Interpreter.h>
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
#include <LibJS/Runtime/Accessor.h>
LibJS: Support reading/writing elements in an Array via Object get/put I'm not completely thrilled about Object::get() and Object::put() doing special-case stuff for arrays, and we should probably come up with a better abstraction for it. But at least it works for now, which is really nice. :^)
2020-03-20 20:51:59 +01:00
#include <LibJS/Runtime/Array.h>
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
#include <LibJS/Runtime/Error.h>
LibJS: Add "constructor" property to constructor prototypes
2020-04-08 11:05:38 +02:00
#include <LibJS/Runtime/GlobalObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/NativeFunction.h>
#include <LibJS/Runtime/NativeProperty.h>
#include <LibJS/Runtime/Object.h>
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
#include <LibJS/Runtime/Shape.h>
LibJS: Implement correct object property ordering This commit introduces a way to get an object's own properties in the correct order. The "correct order" for JS object properties is first all array-like index properties (numeric keys) sorted by insertion order, followed by all string properties sorted by insertion order. Objects also now print correctly in the repl! Before this commit: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { bar: 2, foo: 1, baz: 3 } After: courage ~/js-tests $ js > ({ foo: 1, bar: 2, baz: 3 }) { foo: 1, bar: 2, baz: 3 }
2020-04-28 19:19:31 -07:00
#include <LibJS/Runtime/StringObject.h>
LibJS: Add "Heap" and "Runtime" subdirectories Let's try to keep LibJS tidy as it expands. :^)
2020-03-16 14:20:30 +01:00
#include <LibJS/Runtime/Value.h>
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
namespace JS {
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
PropertyDescriptor PropertyDescriptor::from_dictionary(Interpreter& interpreter, const Object& object)
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
{
PropertyAttributes attributes;
if (object.has_property("configurable")) {
attributes.set_has_configurable();
if (object.get("configurable").value_or(Value(false)).to_boolean())
attributes.set_configurable();
if (interpreter.exception())
return {};
}
if (object.has_property("enumerable")) {
attributes.set_has_enumerable();
if (object.get("enumerable").value_or(Value(false)).to_boolean())
attributes.set_enumerable();
if (interpreter.exception())
return {};
}
if (object.has_property("writable")) {
attributes.set_has_writable();
if (object.get("writable").value_or(Value(false)).to_boolean())
attributes.set_writable();
if (interpreter.exception())
return {};
}
PropertyDescriptor descriptor { attributes, object.get("value"), nullptr, nullptr };
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
auto getter = object.get("get");
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (getter.is_function())
descriptor.getter = &getter.as_function();
auto setter = object.get("set");
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter.exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (setter.is_function())
descriptor.setter = &setter.as_function();
return descriptor;
}
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
Object* Object::create_empty(Interpreter&, GlobalObject& global_object)
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
{
LibJS: Move builtin prototypes to the global object This moves us towards being able to run JavaScript in different global objects without allocating a separate GC heap.
2020-04-18 13:18:06 +02:00
return global_object.heap().allocate<Object>(global_object.object_prototype());
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
}
Object::Object(Object* prototype)
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
{
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
if (prototype) {
m_shape = interpreter().global_object().empty_object_shape();
set_prototype(prototype);
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
// This is the global object
m_shape = interpreter().heap().allocate<Shape>(static_cast<GlobalObject&>(*this));
LibJS: Move the empty object shape from Interpreter to GlobalObject The big remaining hurdle before a GlobalObject-agnostic Interpreter is the fact that Interpreter owns and vends the GlobalObject :^)
2020-04-18 13:56:13 +02:00
}
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
}
Object::~Object()
{
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
Object* Object::prototype()
{
return shape().prototype();
}
const Object* Object::prototype() const
{
return shape().prototype();
}
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
bool Object::set_prototype(Object* new_prototype)
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
{
LibJS+LibWeb: Pass prototype to Object constructor Everyone who constructs an Object must now pass a prototype object when applicable. There's still a fair amount of code that passes something fetched from the Interpreter, but this brings us closer to being able to detach prototypes from Interpreter eventually.
2020-04-18 10:27:57 +02:00
if (prototype() == new_prototype)
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
return true;
if (!m_is_extensible)
return false;
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (shape().is_unique()) {
shape().set_prototype_without_transition(new_prototype);
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
return true;
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
m_shape = m_shape->create_prototype_transition(new_prototype);
LibJS: Disallow changing the prototype of non-extensible objects Object::set_prototype() now returns a boolean indicating success. Setting the prototype to an identical object is always considered successful, even if the object is non-extensible.
2020-06-02 12:32:54 +01:00
return true;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
}
LibJS: Oops, "instanceof" was backwards! Fix the "instanceof" operator to check if the constructor's prototype property occurs anywhere in the prototype chain of the instance object. This patch also adds Object.setPrototypeOf() to make it possible to create a test for this bug. Thanks to DexesTTP for pointing this out! :^)
2020-03-28 19:48:12 +01:00
bool Object::has_prototype(const Object* prototype) const
{
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
for (auto* object = this->prototype(); object; object = object->prototype()) {
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return false;
LibJS: Oops, "instanceof" was backwards! Fix the "instanceof" operator to check if the constructor's prototype property occurs anywhere in the prototype chain of the instance object. This patch also adds Object.setPrototypeOf() to make it possible to create a test for this bug. Thanks to DexesTTP for pointing this out! :^)
2020-03-28 19:48:12 +01:00
if (object == prototype)
return true;
}
return false;
}
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
bool Object::prevent_extensions()
{
m_is_extensible = false;
return true;
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
Value Object::get_own_property(const Object& this_object, PropertyName property_name) const
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
Value value_here;
if (property_name.is_number()) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto existing_property = m_indexed_properties.get(nullptr, property_name.as_number(), false);
if (!existing_property.has_value())
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return {};
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
value_here = existing_property.value().value.value_or(js_undefined());
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
} else {
auto metadata = shape().lookup(property_name.as_string());
if (!metadata.has_value())
return {};
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
value_here = m_storage[metadata.value().offset].value_or(js_undefined());
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
ASSERT(!value_here.is_empty());
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (value_here.is_accessor()) {
return value_here.as_accessor().call_getter(Value(const_cast<Object*>(this)));
}
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (value_here.is_object() && value_here.as_object().is_native_property())
return call_native_property_getter(const_cast<Object*>(&this_object), value_here);
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
return value_here;
}
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
Value Object::get_own_properties(const Object& this_object, GetOwnPropertyMode kind, bool only_enumerable_properties) const
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
{
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* properties_array = Array::create(global_object());
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
// FIXME: Support generic iterables
if (this_object.is_string_object()) {
auto str = static_cast<const StringObject&>(this_object).primitive_string().string();
for (size_t i = 0; i < str.length(); ++i) {
if (kind == GetOwnPropertyMode::Key) {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
properties_array->define_property(i, js_string(interpreter(), String::number(i)));
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else if (kind == GetOwnPropertyMode::Value) {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
properties_array->define_property(i, js_string(interpreter(), String::format("%c", str[i])));
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
entry_array->define_property(0, js_string(interpreter(), String::number(i)));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
entry_array->define_property(1, js_string(interpreter(), String::format("%c", str[i])));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
properties_array->define_property(i, entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
return properties_array;
}
size_t property_index = 0;
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
for (auto& entry : m_indexed_properties) {
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
auto value_and_attributes = entry.value_and_attributes(const_cast<Object*>(&this_object));
if (only_enumerable_properties && !value_and_attributes.attributes.is_enumerable())
continue;
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
if (kind == GetOwnPropertyMode::Key) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
properties_array->define_property(property_index, js_string(interpreter(), String::number(entry.index())));
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else if (kind == GetOwnPropertyMode::Value) {
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
properties_array->define_property(property_index, value_and_attributes.value);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
entry_array->define_property(0, js_string(interpreter(), String::number(entry.index())));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
entry_array->define_property(1, value_and_attributes.value);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (interpreter().exception())
return {};
properties_array->define_property(property_index, entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
++property_index;
}
for (auto& it : this_object.shape().property_table_ordered()) {
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
if (only_enumerable_properties && !it.value.attributes.is_enumerable())
continue;
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
size_t offset = it.value.offset + property_index;
if (kind == GetOwnPropertyMode::Key) {
properties_array->define_property(offset, js_string(interpreter(), it.key));
} else if (kind == GetOwnPropertyMode::Value) {
properties_array->define_property(offset, this_object.get(it.key));
} else {
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* entry_array = Array::create(global_object());
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
entry_array->define_property(0, js_string(interpreter(), it.key));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add Proxy objects Includes all traps except the following: [[Call]], [[Construct]], [[OwnPropertyKeys]]. An important implication of this commit is that any call to any virtual Object method has the potential to throw an exception. These methods were not checked in this commit -- a future commit will have to protect these various method calls throughout the codebase.
2020-06-03 14:34:52 -07:00
entry_array->define_property(1, this_object.get(it.key));
if (interpreter().exception())
return {};
properties_array->define_property(offset, entry_array);
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add Object.{keys,values,entries}()
2020-04-29 18:59:23 -07:00
}
return properties_array;
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
Optional<PropertyDescriptor> Object::get_own_property_descriptor(PropertyName property_name) const
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
Value value;
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes attributes;
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (property_name.is_number()) {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto existing_value = m_indexed_properties.get(nullptr, property_name.as_number(), false);
if (!existing_value.has_value())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
value = existing_value.value().value;
attributes = existing_value.value().attributes;
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
attributes = default_attributes;
} else {
auto metadata = shape().lookup(property_name.as_string());
if (!metadata.has_value())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
return {};
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
value = m_storage[metadata.value().offset];
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (interpreter().exception())
return {};
attributes = metadata.value().attributes;
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
PropertyDescriptor descriptor { attributes, {}, nullptr, nullptr };
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (value.is_object() && value.as_object().is_native_property()) {
auto result = call_native_property_getter(const_cast<Object*>(this), value);
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.value = result.value_or(js_undefined());
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
} else if (value.is_accessor()) {
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
auto& pair = value.as_accessor();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (pair.getter())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.getter = pair.getter();
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
if (pair.setter())
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.setter = pair.setter();
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
} else {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor.value = value.value_or(js_undefined());
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
return descriptor;
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
Value Object::get_own_property_descriptor_object(PropertyName property_name) const
{
auto descriptor_opt = get_own_property_descriptor(property_name);
if (!descriptor_opt.has_value())
return js_undefined();
auto descriptor = descriptor_opt.value();
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* descriptor_object = Object::create_empty(interpreter(), global_object());
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor_object->define_property("enumerable", Value(descriptor.attributes.is_enumerable()));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor_object->define_property("configurable", Value(descriptor.attributes.is_configurable()));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
if (descriptor.is_data_descriptor()) {
descriptor_object->define_property("value", descriptor.value.value_or(js_undefined()));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor_object->define_property("writable", Value(descriptor.attributes.is_writable()));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
} else if (descriptor.is_accessor_descriptor()) {
if (descriptor.getter) {
descriptor_object->define_property("get", Value(descriptor.getter));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
}
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (descriptor.setter) {
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
descriptor_object->define_property("set", Value(descriptor.setter));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
}
LibJS: Add PropertyDescriptor object This new struct is now returned from get_own_property_descriptor. To preserve the old functionality of returning an object, there is now a get_own_property_descriptor_object method, for use in {Object,Reflect}.getOwnPropertyDescriptor(). This change will be useful for the implementation of Proxies, which do a lot of descriptor checks. We want to avoid as many object gets and puts as possible.
2020-06-03 09:40:17 -07:00
}
return descriptor_object;
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
void Object::set_shape(Shape& new_shape)
{
m_storage.resize(new_shape.property_count());
m_shape = &new_shape;
}
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
bool Object::define_property(const FlyString& property_name, const Object& descriptor, bool throw_exceptions)
{
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
bool is_accessor_property = descriptor.has_property("get") || descriptor.has_property("set");
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes attributes;
if (descriptor.has_property("configurable")) {
attributes.set_has_configurable();
if (descriptor.get("configurable").value_or(Value(false)).to_boolean())
attributes.set_configurable();
if (interpreter().exception())
return false;
}
if (descriptor.has_property("enumerable")) {
attributes.set_has_enumerable();
if (descriptor.get("enumerable").value_or(Value(false)).to_boolean())
attributes.set_enumerable();
if (interpreter().exception())
return false;
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (is_accessor_property) {
if (descriptor.has_property("value") || descriptor.has_property("writable")) {
if (throw_exceptions)
interpreter().throw_exception<TypeError>("Accessor property descriptors cannot specify a value or writable key");
return false;
}
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
auto getter = descriptor.get("get").value_or(js_undefined());
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (interpreter().exception())
return {};
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
auto setter = descriptor.get("set").value_or(js_undefined());
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (interpreter().exception())
return {};
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
Function* getter_function { nullptr };
Function* setter_function { nullptr };
if (getter.is_function()) {
getter_function = &getter.as_function();
} else if (!getter.is_undefined()) {
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
interpreter().throw_exception<TypeError>("Accessor descriptor's 'get' field must be a function or undefined");
return false;
}
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
if (setter.is_function()) {
setter_function = &setter.as_function();
} else if (!setter.is_undefined()) {
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
interpreter().throw_exception<TypeError>("Accessor descriptor's 'set' field must be a function or undefined");
return false;
}
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
dbg() << "Defining new property " << property_name << " with accessor descriptor { attributes=" << attributes << ", "
<< "getter=" << getter.to_string_without_side_effects() << ", "
<< "setter=" << setter.to_string_without_side_effects() << "}";
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return define_property(property_name, Accessor::create(interpreter(), getter_function, setter_function), attributes, throw_exceptions);
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
}
auto value = descriptor.get("value");
if (interpreter().exception())
return {};
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (descriptor.has_property("writable")) {
attributes.set_has_writable();
if (descriptor.get("writable").value_or(Value(false)).to_boolean())
attributes.set_writable();
if (interpreter().exception())
return false;
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (interpreter().exception())
return {};
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
dbg() << "Defining new property " << property_name << " with data descriptor { attributes=" << attributes
<< ", value=" << (value.is_empty() ? "<empty>" : value.to_string_without_side_effects()) << " }";
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return define_property(property_name, value, attributes, throw_exceptions);
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
bool Object::define_property(PropertyName property_name, Value value, PropertyAttributes attributes, bool throw_exceptions)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
{
if (property_name.is_number())
return put_own_property_by_index(*this, property_name.as_number(), value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
bool ok;
i32 property_index = property_name.as_string().to_int(ok);
if (ok && property_index >= 0)
return put_own_property_by_index(*this, property_index, value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
return put_own_property(*this, property_name.as_string(), value, attributes, PutOwnPropertyMode::DefineProperty, throw_exceptions);
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
bool Object::put_own_property(Object& this_object, const FlyString& property_name, Value value, PropertyAttributes attributes, PutOwnPropertyMode mode, bool throw_exceptions)
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
{
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
ASSERT(!(mode == PutOwnPropertyMode::Put && value.is_accessor()));
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
if (!is_extensible()) {
dbg() << "Disallow define_property of non-extensible object";
if (throw_exceptions && interpreter().in_strict_mode())
interpreter().throw_exception<TypeError>(String::format("Cannot define property %s on non-extensible object", property_name.characters()));
return false;
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (value.is_accessor()) {
auto& accessor = value.as_accessor();
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
if (accessor.getter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_getter();
LibJS: Refactor Accessor This changes Accessor's m_{getter,setter} from Value to Function* which seems like a better API to me - a getter/setter must either be a function or missing, and the creation of an accessor with other values must be prevented by the parser and Object.defineProperty() anyway. Also add Accessor::set_{getter,setter}() so we can reuse an already created accessor when evaluating an ObjectExpression with getter/setter shorthand syntax.
2020-05-23 23:27:10 +01:00
if (accessor.setter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_setter();
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
auto metadata = shape().lookup(property_name);
LibJS: Implement correct attributes for (almost) all properties Added the ability to include a u8 attributes parameter with all of the various put methods in the Object class. They can be omitted, in which case it defaults to "Writable | Enumerable | Configurable", just like before this commit. All of the attribute values for each property were gathered from SpiderMonkey in the Firefox console. Some properties (e.g. all of the canvas element properties) have undefined property descriptors... not quite sure what that means. Those were left as the default specified above.
2020-04-27 23:05:02 -07:00
bool new_property = !metadata.has_value();
if (new_property) {
LibJS: Switch objects to unique shape after 100 property additions At that point, it seems unlikely that the shape is gonna be shared with other objects, and we avoid getting stuck holding a big bag of shapes.
2020-05-05 18:48:30 +02:00
if (!m_shape->is_unique() && shape().property_count() > 100) {
// If you add more than 100 properties to an object, let's stop doing
// transitions to avoid filling up the heap with shapes.
ensure_shape_is_unique();
}
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (m_shape->is_unique()) {
m_shape->add_property_to_unique_shape(property_name, attributes);
LibJS: Grow storage when adding a property to uniquely-shaped Object Normally the storage would be expanded by set_shape() upon transition to a new shape, but if the shape is already unique, there is no new transition so we have to expand the storage manually.
2020-04-26 19:03:23 +02:00
m_storage.resize(m_shape->property_count());
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
} else {
set_shape(*m_shape->create_put_transition(property_name, attributes));
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
metadata = shape().lookup(property_name);
ASSERT(metadata.has_value());
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::DefineProperty && !metadata.value().attributes.is_configurable() && attributes != metadata.value().attributes) {
LibJS: Add Object.defineProperty() and start caring about attributes We now care (a little bit) about the "configurable" and "writable" property attributes. Property attributes are stored together with the property name in the Shape object. Forward transitions are not attribute-savvy and will cause poor Shape reuse in the case of multiple same-name properties with different attributes. Oh, and this patch also adds Object.getOwnPropertyDescriptor() :^)
2020-04-09 22:15:26 +02:00
dbg() << "Disallow reconfig of non-configurable property";
LibJS: Implement most of the Reflect object
2020-05-01 11:06:27 +01:00
if (throw_exceptions)
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
interpreter().throw_exception<TypeError>(String::format("Cannot change attributes of non-configurable property '%s'", property_name.characters()));
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return false;
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
if (mode == PutOwnPropertyMode::DefineProperty && attributes != metadata.value().attributes) {
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
if (m_shape->is_unique()) {
m_shape->reconfigure_property_in_unique_shape(property_name, attributes);
} else {
set_shape(*m_shape->create_configure_transition(property_name, attributes));
}
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
metadata = shape().lookup(property_name);
dbg() << "Reconfigured property " << property_name << ", new shape says offset is " << metadata.value().offset << " and my storage capacity is " << m_storage.size();
}
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
auto value_here = m_storage[metadata.value().offset];
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::Put && !value_here.is_accessor() && !metadata.value().attributes.is_writable()) {
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
dbg() << "Disallow write to non-writable property";
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return false;
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
}
if (value.is_empty())
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Add property configuration transitions Object.defineProperty() can now change the attributes of a property already on the object. Internally this becomes a shape transition with the TransitionType::Configure. Such transitions don't expand the property storage capacity, but rather simply keep attributes up to date when generating a property table.
2020-04-09 22:55:17 +02:00
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
if (value_here.is_object() && value_here.as_object().is_native_property()) {
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
call_native_property_setter(const_cast<Object*>(&this_object), value_here, value);
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
} else {
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
m_storage[metadata.value().offset] = value;
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
}
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Virtualize access to an Object's own properties Object now has virtual get_own_property() and put_own_property() member functions that can be overridden to provide custom behavior. We use these virtuals to move Array-specific access behavior to Array.
2020-03-21 14:37:34 +01:00
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
bool Object::put_own_property_by_index(Object& this_object, u32 property_index, Value value, PropertyAttributes attributes, PutOwnPropertyMode mode, bool throw_exceptions)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
{
ASSERT(!(mode == PutOwnPropertyMode::Put && value.is_accessor()));
LibJS: Add Object.{isExtensible,preventExtensions}()
2020-06-01 21:13:16 -07:00
if (!is_extensible()) {
dbg() << "Disallow define_property of non-extensible object";
if (throw_exceptions && interpreter().in_strict_mode())
interpreter().throw_exception<TypeError>(String::format("Cannot define property %d on non-extensible object", property_index));
return false;
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (value.is_accessor()) {
auto& accessor = value.as_accessor();
if (accessor.getter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_getter();
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (accessor.setter())
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
attributes.set_has_setter();
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
}
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto existing_property = m_indexed_properties.get(nullptr, property_index, false);
auto new_property = !existing_property.has_value();
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
PropertyAttributes existing_attributes = new_property ? 0 : existing_property.value().attributes;
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::DefineProperty && !existing_attributes.is_configurable() && attributes != existing_attributes) {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
dbg() << "Disallow reconfig of non-configurable property";
if (throw_exceptions)
interpreter().throw_exception<TypeError>(String::format("Cannot change attributes of non-configurable property %d", property_index));
return false;
}
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
auto value_here = new_property ? Value() : existing_property.value().value;
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!new_property && mode == PutOwnPropertyMode::Put && !value_here.is_accessor() && !existing_attributes.is_writable()) {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
dbg() << "Disallow write to non-writable property";
return false;
}
if (value.is_empty())
return true;
if (value_here.is_object() && value_here.as_object().is_native_property()) {
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
call_native_property_setter(const_cast<Object*>(&this_object), value_here, value);
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
} else {
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
m_indexed_properties.put(&this_object, property_index, value, attributes, mode == PutOwnPropertyMode::Put);
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
}
return true;
}
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
Value Object::delete_property(PropertyName property_name)
{
ASSERT(property_name.is_valid());
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (property_name.is_number())
return Value(m_indexed_properties.remove(property_name.as_number()));
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
bool ok;
int property_index = property_name.as_string().to_int(ok);
if (ok && property_index >= 0)
return Value(m_indexed_properties.remove(property_name.as_number()));
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
auto metadata = shape().lookup(property_name.as_string());
if (!metadata.has_value())
return Value(true);
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
if (!metadata.value().attributes.is_configurable())
LibJS: Implement basic support for the "delete" operator It turns out "delete" is actually a unary op :) This patch implements deletion of object properties, it doesn't yet work for casually deleting properties from the global object. When deleting a property from an object, we switch that object to having a unique shape, no longer sharing shapes with others. Once an object has a unique shape, it no longer needs to care about shape transitions.
2020-04-26 13:53:40 +02:00
return Value(false);
size_t deleted_offset = metadata.value().offset;
ensure_shape_is_unique();
shape().remove_property_from_unique_shape(property_name.as_string(), deleted_offset);
m_storage.remove(deleted_offset);
return Value(true);
}
void Object::ensure_shape_is_unique()
{
if (shape().is_unique())
return;
m_shape = m_shape->create_unique_clone();
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
Value Object::get_by_index(u32 property_index) const
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
{
const Object* object = this;
while (object) {
LibJS: Implement indexed access for StringObject
2020-05-01 13:20:47 +01:00
if (is_string_object()) {
auto& string = static_cast<const StringObject*>(this)->primitive_string().string();
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (property_index < string.length())
LibJS: Implement indexed access for StringObject
2020-05-01 13:20:47 +01:00
return js_string(heap(), string.substring(property_index, 1));
return js_undefined();
}
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (static_cast<size_t>(property_index) < object->m_indexed_properties.array_like_size()) {
auto result = object->m_indexed_properties.get(const_cast<Object*>(this), property_index);
if (interpreter().exception())
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
if (result.has_value() && !result.value().value.is_empty())
return result.value().value;
return {};
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
}
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
object = object->prototype();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
}
return {};
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
Value Object::get(PropertyName property_name) const
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (property_name.is_number())
return get_by_index(property_name.as_number());
auto property_string = property_name.to_string();
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
bool ok;
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
i32 property_index = property_string.to_int(ok);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
if (ok && property_index >= 0)
return get_by_index(property_index);
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
const Object* object = this;
while (object) {
LibJS: Use correct |this| value when getting/setting native properties
2020-03-24 14:46:05 +01:00
auto value = object->get_own_property(*this, property_name);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Stop using Optional<Value> in favor of Value's empty state JS::Value already has the empty state ({} or Value() gives you one.) Use this instead of wrapping Value in Optional in some places. I've also added Value::value_or(Value) so you can easily provide a fallback value when one is not present.
2020-04-25 18:43:34 +02:00
if (!value.is_empty())
return value;
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
object = object->prototype();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Add basic prototype support Object will now traverse up the prototype chain when doing a get(). When a function is called on an object, that object will now also be the "this" value inside the function. This stuff is probably not very correct, but we will improve things as we go! :^)
2020-03-15 15:01:10 +01:00
}
LibJS: Allow function calls with missing arguments We were interpreting "undefined" as a variable lookup failure in some cases and throwing a ReferenceError exception instead of treating it as the valid value "undefined". This patch wraps the result of variable lookup in Optional<>, which allows us to only throw ReferenceError when lookup actually fails.
2020-03-27 12:54:18 +01:00
return {};
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
bool Object::put_by_index(u32 property_index, Value value)
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
{
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
ASSERT(!value.is_empty());
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
// If there's a setter in the prototype chain, we go to the setter.
// Otherwise, it goes in the own property storage.
Object* object = this;
while (object) {
auto existing_value = object->m_indexed_properties.get(nullptr, property_index, false);
if (existing_value.has_value()) {
auto value_here = existing_value.value();
if (value_here.value.is_accessor()) {
value_here.value.as_accessor().call_setter(object, value);
return true;
}
if (value_here.value.is_object() && value_here.value.as_object().is_native_property()) {
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
call_native_property_setter(const_cast<Object*>(this), value_here.value, value);
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
return true;
}
}
object = object->prototype();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
}
return put_own_property_by_index(*this, property_index, value, default_attributes, PutOwnPropertyMode::Put);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
bool Object::put(PropertyName property_name, Value value)
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
if (property_name.is_number())
return put_by_index(property_name.as_number(), value);
LibJS: Support array holes, encoded as empty JS::Value This patch adds a new kind of JS::Value, the empty value. It's what you get when you do JSValue() (or most commonly, {} in C++.) An empty Value signifies the absence of a value, and should never be visible to JavaScript itself. As of right now, it's used for array holes and as a return value when an exception has been thrown and we just want to unwind. This patch is a bit of a mess as I had to fix a whole bunch of code that was relying on JSValue() being undefined, etc.
2020-04-06 20:24:45 +02:00
ASSERT(!value.is_empty());
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
auto property_string = property_name.to_string();
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
bool ok;
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
i32 property_index = property_string.to_int(ok);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
if (ok && property_index >= 0)
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return put_by_index(property_index, value);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Object::put() shouldn't create own properties on prototype chain Unless there is a setter present on the prototype chain, put() should only set own properties on the object itself. Fixes #1588.
2020-04-02 21:34:31 +02:00
// If there's a setter in the prototype chain, we go to the setter.
// Otherwise, it goes in the own property storage.
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
Object* object = this;
while (object) {
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
auto metadata = object->shape().lookup(property_string);
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
if (metadata.has_value()) {
auto value_here = object->m_storage[metadata.value().offset];
LibJS: Add getter/setter support This patch adds a GetterSetterPair object. Values can now store pointers to objects of this type. These objects are created when using Object.defineProperty and providing an accessor descriptor.
2020-05-21 11:14:23 -07:00
if (value_here.is_accessor()) {
value_here.as_accessor().call_setter(Value(this), value);
return true;
}
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
if (value_here.is_object() && value_here.as_object().is_native_property()) {
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
call_native_property_setter(const_cast<Object*>(this), value_here, value);
LibJS: Return a bool from Object::put* to indicate success
2020-04-30 20:01:54 +01:00
return true;
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
}
}
object = object->prototype();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Implement basic object property assignment This is pretty naive, we just walk up the prototype chain and call any NativeProperty setter that we find. If we don't find one, we put/set the value as an own property of the object itself.
2020-03-19 17:39:13 +01:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return put_own_property(*this, property_string, value, default_attributes, PutOwnPropertyMode::Put);
LibJS: Add a PropertyName class that represents a string or a number Now that we have two separate storages for Object properties depending on what kind of index they have, it's nice to have an abstraction that still allows us to say "here's a property name". We use PropertyName to always choose the optimal storage path directly while interpreting the AST. :^)
2020-04-06 17:08:23 +02:00
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
bool Object::define_native_function(const FlyString& property_name, AK::Function<Value(Interpreter&)> native_function, i32 length, PropertyAttributes attribute)
LibJS: Add Object::put_native_function() for convenience This makes it a little bit nicer to add native function properties to JavaScript objects. Thanks to Sergey for suggesting it! :^)
2020-03-13 11:06:32 +01:00
{
LibJS+LibWeb: Remove a bunch of calls to Interpreter::global_object() Objects should get the GlobalObject from themselves instead. However, it's not yet available during construction so this only switches code that happens after construction. To support multiple global objects, Interpreter needs to stop holding on to "the" global object and let each object graph own their global.
2020-06-08 12:25:45 +02:00
auto* function = NativeFunction::create(interpreter(), global_object(), property_name, move(native_function));
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
function->define_property("length", Value(length), Attribute::Configurable);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
function->define_property("name", js_string(heap(), property_name), Attribute::Configurable);
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return {};
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return define_property(property_name, function, attribute);
LibJS: Add Object::put_native_function() for convenience This makes it a little bit nicer to add native function properties to JavaScript objects. Thanks to Sergey for suggesting it! :^)
2020-03-13 11:06:32 +01:00
}
LibJS: Distinguish between omitted descriptor attributes and false ones When calling Object.defineProperty, there is now a difference between omitting a descriptor attribute and specifying that it is false. For example, "{}" and "{ configurable: false }" will have different attribute values.
2020-06-02 17:13:09 -07:00
bool Object::define_native_property(const FlyString& property_name, AK::Function<Value(Interpreter&)> getter, AK::Function<void(Interpreter&, Value)> setter, PropertyAttributes attribute)
LibJS: Add a mechanism for callback-based object properties This patch adds NativeProperty, which can be used to implement object properties that have C++ getters and/or setters. Use this to move String.prototype.length to its correct place. :^)
2020-03-15 18:15:44 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return define_property(property_name, heap().allocate<NativeProperty>(move(getter), move(setter)), attribute);
LibJS: Add a mechanism for callback-based object properties This patch adds NativeProperty, which can be used to implement object properties that have C++ getters and/or setters. Use this to move String.prototype.length to its correct place. :^)
2020-03-15 18:15:44 +01:00
}
LibJS: Make the GC marking phase cycle-proof Don't visit cells that are already marked. This prevents the marking phase from looping forever when two cells refer to each other. Also do the marking directly from the CellVisitor, removing another unnecessary phase of the collector. :^)
2020-03-09 22:11:22 +01:00
void Object::visit_children(Cell::Visitor& visitor)
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
{
LibJS: Make the GC marking phase cycle-proof Don't visit cells that are already marked. This prevents the marking phase from looping forever when two cells refer to each other. Also do the marking directly from the CellVisitor, removing another unnecessary phase of the collector. :^)
2020-03-09 22:11:22 +01:00
Cell::visit_children(visitor);
LibJS: Start implementing object shapes This patch adds JS::Shape, which implements a transition tree for our Object class. Object property keys, prototypes and attributes are now stored in a Shape, and each Object has a Shape. When adding a property to an Object, we make a transition from the old Shape to a new Shape. If we've made the same exact transition in the past (with another Object), we reuse the same transition and both objects may now share a Shape. This will become the foundation of inline caching and other engine optimizations in the future. :^)
2020-04-02 19:32:21 +02:00
visitor.visit(m_shape);
LibJS: Object needs to protect values in its storage Otherwise the garbage collector will eat them way too soon! This made it impossible to use "js -g" without crashing.
2020-04-06 12:33:27 +02:00
for (auto& value : m_storage)
visitor.visit(value);
LibJS: Add a number-indexed property storage to all Objects Objects can have both named and indexed properties. Previously we kept all property names as strings. This patch separates named and indexed properties and splits them between Object::m_storage and m_elements. This allows us to do much faster array-style access using numeric indices. It also makes the Array class much less special, since all Objects now have number-indexed storage. :^)
2020-04-06 16:53:02 +02:00
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
for (auto& value : m_indexed_properties.values_unordered())
visitor.visit(value.value);
LibJS: Add a basic mark&sweep garbage collector :^) Objects can now be allocated via the interpreter's heap. Objects that are allocated in this way will need to be provably reachable from at least one of the known object graph roots. The roots are currently determined by Heap::collect_roots(). Anything that wants be collectable garbage should inherit from Cell, the fundamental atom of the GC heap. This is pretty neat! :^)
2020-03-08 19:23:58 +01:00
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
bool Object::has_property(PropertyName property_name) const
LibJS: Add Object::has_property() Like Object::has_own_property() but going down the prototype chain.
2020-04-30 20:03:40 +01:00
{
const Object* object = this;
while (object) {
if (object->has_own_property(property_name))
return true;
object = object->prototype();
LibJS: Add interpreter exception checks
2020-06-07 10:53:14 -07:00
if (interpreter().exception())
return false;
LibJS: Add Object::has_property() Like Object::has_own_property() but going down the prototype chain.
2020-04-30 20:03:40 +01:00
}
return false;
}
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
bool Object::has_own_property(PropertyName property_name) const
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
{
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
auto has_indexed_property = [&](u32 index) -> bool {
LibJS: Implement indexed access for StringObject
2020-05-01 13:20:47 +01:00
if (is_string_object())
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
return index < static_cast<const StringObject*>(this)->primitive_string().string().length();
LibJS: Object index properties have descriptors; Handle sparse indices This patch adds an IndexedProperties object for storing indexed properties within an Object. This accomplishes two goals: indexed properties now have an associated descriptor, and objects now gracefully handle sparse properties. The IndexedProperties class is a wrapper around two other classes, one for simple indexed properties storage, and one for general indexed property storage. Simple indexed property storage is the common-case, and is simply a vector of properties which all have attributes of default_attributes (writable, enumerable, and configurable). General indexed property storage is for a collection of indexed properties where EITHER one or more properties have attributes other than default_attributes OR there is a property with a large index (in particular, large is '200' or higher). Indexed properties are now treated relatively the same as storage within the various Object methods. Additionally, there is a custom iterator class for IndexedProperties which makes iteration easy. The iterator skips empty values by default, but can be configured otherwise. Likewise, it evaluates getters by default, but can be set not to.
2020-05-27 11:35:09 -07:00
return m_indexed_properties.has_index(index);
LibJS: Simplify and normalize publicly-exposed Object functions Previously, the Object class had many different types of functions for each action. For example: get_by_index, get(PropertyName), get(FlyString). This is a bit verbose, so these methods have been shortened to simply use the PropertyName structure. The methods then internally call _by_index if necessary. Note that the _by_index have been made private to enforce this change. Secondly, a clear distinction has been made between "putting" and "defining" an object property. "Putting" should mean modifying a (potentially) already existing property. This is akin to doing "a.b = 'foo'". This implies two things about put operations: - They will search the prototype chain for setters and call them, if necessary. - If no property exists with a particular key, the put operation should create a new property with the default attributes (configurable, writable, and enumerable). In contrast, "defining" a property should completely overwrite any existing value without calling setters (if that property is configurable, of course). Thus, all of the many JS objects have had any "put" calls changed to "define_property" calls. Additionally, "put_native_function" and "put_native_property" have had their "put" replaced with "define". Finally, "put_own_property" has been made private, as all necessary functionality should be exposed with the put and define_property methods.
2020-05-26 21:33:37 -07:00
};
if (property_name.is_number())
return has_indexed_property(property_name.as_number());
bool ok;
i32 property_index = property_name.as_string().to_int(ok);
if (ok && property_index >= 0)
return has_indexed_property(property_index);
return shape().lookup(property_name.as_string()).has_value();
LibJS: Add ObjectPrototype and implement hasOwnProperty() All Objects will now have ObjectPrototype as their prototype, unless overridden.
2020-03-15 15:25:43 +01:00
}
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
Value Object::to_primitive(Value::PreferredType preferred_type) const
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
{
Value result = js_undefined();
switch (preferred_type) {
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
case Value::PreferredType::Default:
case Value::PreferredType::Number: {
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
result = value_of();
if (result.is_object()) {
result = to_string();
}
break;
}
LibJS: Implement standard semantics for relational operators (#2417) Previously, the relational operators where casting any value to double and comparing the results according to C++ semantics. This patch makes the relational operators in JS behave according to the standard specification. Since we don't have BigInt yet, the implementation doesn't take it into account. Moved PreferredType from Object to Value. Value::to_primitive now passes preferred_type to Object::to_primitive.
2020-05-28 17:19:59 +02:00
case Value::PreferredType::String: {
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
result = to_string();
if (result.is_object())
result = value_of();
break;
}
}
ASSERT(!result.is_object());
return result;
}
Value Object::to_string() const
{
LibJS: Make Object::to_string() call the "toString" property if present
2020-04-05 18:18:24 +02:00
auto to_string_property = get("toString");
LibJS: Simplify a Value type check in Object::to_string()
2020-05-06 16:40:08 +02:00
if (to_string_property.is_function()) {
LibJS: Add Value::{is, as}_function()
2020-05-06 11:52:53 +01:00
auto& to_string_function = to_string_property.as_function();
LibJS: Throw error in Object::to_string() if string conversion fails
2020-04-29 16:29:26 +01:00
auto& interpreter = const_cast<Object*>(this)->interpreter();
LibJS: Handle non-string primitive values in Object::to_string()
2020-04-29 16:36:38 +01:00
auto to_string_result = interpreter.call(to_string_function, const_cast<Object*>(this));
if (to_string_result.is_object())
LibJS: Throw error in Object::to_string() if string conversion fails
2020-04-29 16:29:26 +01:00
interpreter.throw_exception<TypeError>("Cannot convert object to string");
if (interpreter.exception())
return {};
LibJS: Add side-effect-free version of Value::to_string() There are now two API's on Value: - Value::to_string(Interpreter&) -- may throw. - Value::to_string_without_side_effects() -- will never throw. These are some pretty big sweeping changes, so it's possible that I did some part the wrong way. We'll work it out as we go. :^) Fixes #2123.
2020-05-15 13:39:24 +02:00
auto* string = to_string_result.to_primitive_string(interpreter);
if (interpreter.exception())
return {};
return string;
LibJS: Make Object::to_string() call the "toString" property if present
2020-04-05 18:18:24 +02:00
}
LibJS: Loosen type system This commits makes effort towards tolerating some of javascript's quirks when it comes to its type system, note that the interpreter's way of handling type coercion is still not mature at all, for example, we still have to implement NaN instead of just crashing when trying to parse a string and failing.
2020-03-16 00:19:41 +02:00
return js_string(heap(), String::format("[object %s]", class_name()));
}
LibJS: Make Object::to_string() call the "toString" property if present
2020-04-05 18:18:24 +02:00
LibJS: Make Object::invoke() non-const As suggested in #2431's code review.
2020-05-29 12:20:14 +01:00
Value Object::invoke(const FlyString& property_name, Optional<MarkedValueList> arguments)
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
{
LibJS: Make Object::invoke() non-const As suggested in #2431's code review.
2020-05-29 12:20:14 +01:00
auto& interpreter = this->interpreter();
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
auto property = get(property_name).value_or(js_undefined());
if (interpreter.exception())
return {};
if (!property.is_function()) {
interpreter.throw_exception<TypeError>(String::format("%s is not a function", property.to_string_without_side_effects().characters()));
return {};
}
LibJS: Make Object::invoke() non-const As suggested in #2431's code review.
2020-05-29 12:20:14 +01:00
return interpreter.call(property.as_function(), this, move(arguments));
LibJS: Add Object::invoke()
2020-05-28 19:12:34 +01:00
}
LibJS: Object.getOwnPropertyDescriptor works properly with accessors
2020-05-29 20:10:21 -07:00
Value Object::call_native_property_getter(Object* this_object, Value property) const
{
ASSERT(property.is_object());
ASSERT(property.as_object().is_native_property());
auto& native_property = static_cast<NativeProperty&>(property.as_object());
auto& call_frame = interpreter().push_call_frame();
call_frame.this_value = this_object;
auto result = native_property.get(interpreter());
interpreter().pop_call_frame();
return result;
}
void Object::call_native_property_setter(Object* this_object, Value property, Value value) const
{
ASSERT(property.is_object());
ASSERT(property.as_object().is_native_property());
auto& native_property = static_cast<NativeProperty&>(property.as_object());
auto& call_frame = interpreter().push_call_frame();
call_frame.this_value = this_object;
native_property.set(interpreter(), value);
interpreter().pop_call_frame();
}
LibJS: Start building a JavaScript engine for SerenityOS :^) I always tell people to start building things by working on the thing that seems the most interesting right now. The most interesting thing here was an AST + simple interpreter, so that's where we start! There is no lexer or parser yet, we build an AST directly and then execute it in the interpreter, producing a return value. This seems like the start of something interesting. :^)
2020-03-07 19:42:11 +01:00
}
Reference in a new issue Copy permalink