f9705eb2f4
Instead of passing a GlobalObject everywhere, we will simply pass a VM, from which we can get everything we need: common names, the current realm, symbols, arguments, the heap, and a few other things. In some places we already don't actually need a global object and just do it for consistency - no more `auto& vm = global_object.vm();`! This will eventually automatically fix the "wrong realm" issue we have in some places where we (incorrectly) use the global object from the allocating object, e.g. in call() / construct() implementations. When only ever a VM is passed around, this issue can't happen :^) I've decided to split this change into a series of patches that should keep each commit down do a somewhat manageable size.
32 lines
891 B
C++
32 lines
891 B
C++
/*
|
|
* Copyright (c) 2021-2022, Tim Flynn <trflynn89@serenityos.org>
|
|
*
|
|
* SPDX-License-Identifier: BSD-2-Clause
|
|
*/
|
|
|
|
#pragma once
|
|
|
|
#include <LibJS/Runtime/NativeFunction.h>
|
|
|
|
namespace JS::Intl {
|
|
|
|
class DateTimeFormatConstructor final : public NativeFunction {
|
|
JS_OBJECT(DateTimeFormatConstructor, NativeFunction);
|
|
|
|
public:
|
|
explicit DateTimeFormatConstructor(Realm&);
|
|
virtual void initialize(Realm&) override;
|
|
virtual ~DateTimeFormatConstructor() override = default;
|
|
|
|
virtual ThrowCompletionOr<Value> call() override;
|
|
virtual ThrowCompletionOr<Object*> construct(FunctionObject& new_target) override;
|
|
|
|
private:
|
|
virtual bool has_constructor() const override { return true; }
|
|
|
|
JS_DECLARE_NATIVE_FUNCTION(supported_locales_of);
|
|
};
|
|
|
|
ThrowCompletionOr<DateTimeFormat*> initialize_date_time_format(VM&, DateTimeFormat&, Value locales_value, Value options_value);
|
|
|
|
}
|