Stowage/ladybird
2
0
Fork 0
mirror of https://github.com/LadybirdBrowser/ladybird.git synced 2025-10-19 23:53:20 +00:00
Code Issues Projects Releases Packages Wiki Activity
ladybird/Libraries/LibJS/Runtime/MapIterator.h

42 lines
1 KiB
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
*/
#pragma once
LibJS: Allow advancing built-in iterators without result object creation Expose a method on built-in iterators that allows retrieving the next iteration result without allocating a JS::Object. This change is a preparation for optimizing for..of and for..in loops.
2025-04-30 16:29:41 +03:00
#include <LibJS/Runtime/Iterator.h>
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
#include <LibJS/Runtime/Map.h>
#include <LibJS/Runtime/Object.h>
namespace JS {
LibJS: Enable EXPLICIT_SYMBOL_EXPORT
2025-06-28 21:39:13 -07:00
class JS_API MapIterator final : public Object
LibJS: Allow advancing built-in iterators without result object creation Expose a method on built-in iterators that allows retrieving the next iteration result without allocating a JS::Object. This change is a preparation for optimizing for..of and for..in loops.
2025-04-30 16:29:41 +03:00
, public BuiltinIterator {
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
JS_OBJECT(MapIterator, Object);
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC_DECLARE_ALLOCATOR(MapIterator);
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
public:
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
static GC::Ref<MapIterator> create(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
Libraries: Use default constructors/destructors in LibJS https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cother-other-default-operation-rules "The compiler is more likely to get the default semantics right and you cannot implement these functions better than the compiler."
2022-03-14 10:25:06 -06:00
virtual ~MapIterator() override = default;
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: Do more comprehensive check if `next()` fast path is possible Before this change each built-in iterator object has a boolean `m_next_method_was_redefined`. If user code later changed the iterator’s prototype (e.g. `Object.setPrototypeOf()`), we still believed the built-in fast-path was safe and skipped the user supplied override, producing wrong results. With this change `BuiltinIterator::as_builtin_iterator_if_next_is_not_redefined()` looks up the current `next` property and verifies that it is still the built-in native function.
2025-06-01 18:44:18 +02:00
BuiltinIterator* as_builtin_iterator_if_next_is_not_redefined(IteratorRecord const&) override;
LibJS: Allow advancing built-in iterators without result object creation Expose a method on built-in iterators that allows retrieving the next iteration result without allocating a JS::Object. This change is a preparation for optimizing for..of and for..in loops.
2025-04-30 16:29:41 +03:00
ThrowCompletionOr<void> next(VM&, bool& done, Value& value) override;
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
private:
friend class MapIteratorPrototype;
LibJS: Hide all the constructors! Now that the GC allocator is able to invoke Cell subclass constructors directly via friendship, we no longer need to keep them public. :^)
2022-08-28 23:51:28 +02:00
explicit 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
virtual void visit_edges(Cell::Visitor&) override;
LibGC+Everywhere: Factor out a LibGC from LibJS Resulting in a massive rename across almost everywhere! Alongside the namespace change, we now have the following names: * JS::NonnullGCPtr -> GC::Ref * JS::GCPtr -> GC::Ptr * JS::HeapFunction -> GC::Function * JS::CellImpl -> GC::Cell * JS::Handle -> GC::Root
2024-11-15 04:01:23 +13:00
GC::Ref<Map> m_map;
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
bool m_done { false };
Object::PropertyKind m_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
Map::ConstIterator m_iterator;
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
};
}
Reference in a new issue Copy permalink