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/Userland/Libraries/LibJS/Runtime/MapIterator.cpp

32 lines
787 B
C++
Raw Normal View History

LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
/*
* Copyright (c) 2021, Idan Horowitz <idan.horowitz@serenityos.org>
*
* SPDX-License-Identifier: BSD-2-Clause
*/
#include <LibJS/Runtime/GlobalObject.h>
#include <LibJS/Runtime/MapIterator.h>
namespace JS {
LibJS+LibWeb: Replace GlobalObject with Realm in create() functions This is a continuation of the previous two commits. As allocating a JS cell already primarily involves a realm instead of a global object, and we'll need to pass one to the allocate() function itself eventually (it's bridged via the global object right now), the create() functions need to receive a realm as well. The plan is for this to be the highest-level function that actually receives a realm and passes it around, AOs on an even higher level will use the "current realm" concept via VM::current_realm() as that's what the spec assumes; passing around realms (or global objects, for that matter) on higher AO levels is pointless and unlike for allocating individual objects, which may happen outside of regular JS execution, we don't need control over the specific realm that is being used there.
2022-08-16 00:20:49 +01:00
MapIterator* MapIterator::create(Realm& realm, Map& map, Object::PropertyKind iteration_kind)
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
{
LibJS: Move intrinsics to the realm Intrinsics, i.e. mostly constructor and prototype objects, but also things like empty and new object shape now live on a new heap-allocated JS::Intrinsics object, thus completing the long journey of taking all the magic away from the global object. This represents the Realm's [[Intrinsics]] slot in the spec and matches its existing [[GlobalObject]] / [[GlobalEnv]] slots in terms of architecture. In the majority of cases it should now be possibly to fully allocate a regular object without the global object existing, and in fact that's what we do now - the realm is allocated before the global object, and the intrinsics between both :^)
2022-08-27 00:54:55 +01:00
return realm.heap().allocate<MapIterator>(realm, map, iteration_kind, *realm.intrinsics().map_iterator_prototype());
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
}
LibJS: Consistently make prototype the last argument in Object ctors This is so that we can reliably allocate them in a template function, e.g. in ordinary_create_from_constructor(): global_object.heap().allocate<T>( global_object, forward<Args>(args)..., *prototype); The majority of objects already take the prototype as the last argument, so I updated the ones that didn't.
2021-06-19 23:21:08 +01:00
MapIterator::MapIterator(Map& map, Object::PropertyKind iteration_kind, Object& prototype)
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
: Object(prototype)
, m_map(map)
, m_iteration_kind(iteration_kind)
LibJS: Make Map iterators independent of the underlying hashmap This implements ordered maps as a pair of an RBTree for key order, and an underlying unordered hash map for storage. Fixes (part of) #11004.
2022-02-09 16:34:52 +03:30
, m_iterator(static_cast<Map const&>(map).begin())
LibJS: Add the MapIterator built-in and the key/values/entries methods While this implementation should be complete it is based on HashMap's iterator, which currently follows bucket-order instead of the required insertion order. This can be simply fixed by replacing the underlying HashMap member in Map with an enhanced one that maintains a linked list in insertion order.
2021-06-12 23:58:03 +03:00
{
}
void MapIterator::visit_edges(Cell::Visitor& visitor)
{
Base::visit_edges(visitor);
visitor.visit(&m_map);
}
}
Reference in a new issue Copy permalink