b99cc7d050
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.
35 lines
1 KiB
C++
35 lines
1 KiB
C++
/*
|
|
* Copyright (c) 2021, David Tuin <davidot@serenityos.org>
|
|
* Copyright (c) 2022, Linus Groh <linusg@serenityos.org>
|
|
*
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#include <LibJS/Runtime/Iterator.h>
|
|
#include <LibJS/Runtime/Object.h>
|
|
|
|
namespace JS {
|
|
|
|
// 27.1.4.3 Properties of Async-from-Sync Iterator Instances, https://tc39.es/ecma262/#sec-properties-of-async-from-sync-iterator-instances
|
|
class AsyncFromSyncIterator final : public Object {
|
|
JS_OBJECT(AsyncFromSyncIterator, Object);
|
|
|
|
public:
|
|
static AsyncFromSyncIterator* create(Realm&, Iterator sync_iterator_record);
|
|
|
|
explicit AsyncFromSyncIterator(Realm&, Iterator sync_iterator_record);
|
|
virtual void initialize(Realm&) override;
|
|
virtual ~AsyncFromSyncIterator() override = default;
|
|
|
|
void visit_edges(Visitor& visitor) override;
|
|
|
|
Iterator& sync_iterator_record() { return m_sync_iterator_record; }
|
|
Iterator const& sync_iterator_record() const { return m_sync_iterator_record; }
|
|
|
|
private:
|
|
Iterator m_sync_iterator_record; // [[SyncIteratorRecord]]
|
|
};
|
|
|
|
}
|