github
/
duktape
mirror of https://github.com/svaarala/duktape.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
9412 Commits
65 Branches
60 Tags
84 MiB
Tree: 64776b8c0f
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '64776b8c0f'
${ noResults }
duktape/src-input/duk_bi_object.c

804 lines
24 KiB
Raw Normal View History

a bunch of builtins
12 years ago
/*
* Object built-ins
*/
#include "duk_internal.h"
Make built-ins optional in metadata and source
8 years ago
/* Needed even when Object built-in disabled. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_to_string(duk_hthread *thr) {
Make built-ins optional in metadata and source
8 years ago
duk_tval *tv;
Add support for @@toStringTag
7 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
tv = DUK_HTHREAD_THIS_PTR(thr);
Add support for @@toStringTag
7 years ago
duk_push_class_string_tval(thr, tv, 0 /*avoid_side_effects*/);
Make built-ins optional in metadata and source
8 years ago
return 1;
}
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor(duk_hthread *thr) {
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
duk_uint_t arg_mask;
a bunch of builtins
12 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
arg_mask = duk_get_type_mask(thr, 0);
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
if (!duk_is_constructor_call(thr) && /* not a constructor call */
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
((arg_mask & (DUK_TYPE_MASK_NULL | DUK_TYPE_MASK_UNDEFINED)) == 0)) { /* and argument not null or undefined */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
duk_to_object(thr, 0);
a bunch of builtins
12 years ago
return 1;
}
promote plain buffer and pointer values to Buffer and Pointer objects in Object constructor (consistent with behavior for other primitive types)
11 years ago
/* Pointer and buffer primitive values are treated like other
* primitives values which have a fully fledged object counterpart:
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
* promote to an object value. Lightfuncs and plain buffers are
* coerced with ToObject() even they could also be returned as is.
promote plain buffer and pointer values to Buffer and Pointer objects in Object constructor (consistent with behavior for other primitive types)
11 years ago
*/
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
if (arg_mask & (DUK_TYPE_MASK_OBJECT |
DUK_TYPE_MASK_STRING |
DUK_TYPE_MASK_BOOLEAN |
DUK_TYPE_MASK_NUMBER |
DUK_TYPE_MASK_POINTER |
DUK_TYPE_MASK_BUFFER |
DUK_TYPE_MASK_LIGHTFUNC)) {
/* For DUK_TYPE_OBJECT the coercion is a no-op and could
* be checked for explicitly, but Object(obj) calls are
* not very common so opt for minimal footprint.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
duk_to_object(thr, 0);
a bunch of builtins
12 years ago
return 1;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
(void) duk_push_object_helper(thr,
Explicit lexenv/varenv in duk_hcompfunc
9 years ago
DUK_HOBJECT_FLAG_EXTENSIBLE |
Add DUK_HOBJECT_FLAG_FASTREFS for DECREF/marking When the flag is set, there is either no subclass C struct for the duk_hobject, or there is a subclass C struct but there are no references needing DECREF/marking in the struct. This allows DECREF and mark-and-sweep to handle duk_hobjects with less overhead for the common cases of plain objects and arrays (and some other less commonly collected structs like duk_hnatfunc). Also change Duktape.Thread.prototype internal class from Thread to Object: with the other changes internal code now assumes that if an object's class is Thread, it has the duk_hthread memory layout which wouldn't be the case for Duktape.Thread.prototype.
8 years ago
DUK_HOBJECT_FLAG_FASTREFS |
Explicit lexenv/varenv in duk_hcompfunc
9 years ago
DUK_HOBJECT_CLASS_AS_FLAGS(DUK_HOBJECT_CLASS_OBJECT),
DUK_BIDX_OBJECT_PROTOTYPE);
a bunch of builtins
12 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn't have to, which is convenient here.
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) && defined(DUK_USE_ES6)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_assign(duk_hthread *thr) {
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn't have to, which is convenient here.
8 years ago
duk_idx_t nargs;
duk_int_t idx;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
nargs = duk_get_top_require_min(thr, 1 /*min_top*/);
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn't have to, which is convenient here.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr <-> ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there's already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as "void duk_foo(duk_context *ctx);" is then defined as "void duk_foo(duk_hthread *thr);".
7 years ago
duk_to_object(thr, 0);
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn't have to, which is convenient here.
8 years ago
for (idx = 1; idx < nargs; idx++) {
/* E7 19.1.2.1 (step 4a) */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (duk_is_null_or_undefined(thr, idx)) {
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
continue;
}
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* duk_enum() respects ES2015+ [[OwnPropertyKeys]] ordering, which is
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
* convenient here.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_to_object(thr, idx);
duk_enum(thr, idx, DUK_ENUM_OWN_PROPERTIES_ONLY);
while (duk_next(thr, -1, 1 /*get_value*/)) {
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
/* [ target ... enum key value ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_put_prop(thr, 0);
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
/* [ target ... enum ] */
}
Small footprint optimizations for Object/Reflect
8 years ago
/* Could pop enumerator, but unnecessary because of duk_set_top()
* below.
*/
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_set_top(thr, 1);
Implement ES6 Object.assign() duk_enum() respects ES6 [[OwnPropertyKeys]] ordering even though it doesn&#39;t have to, which is convenient here.
8 years ago
return 1;
}
#endif
Implement Object.is() and duk_samevalue() API call
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) && defined(DUK_USE_ES6)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_is(duk_hthread *thr) {
DUK_ASSERT_TOP(thr, 2);
duk_push_boolean(thr, duk_samevalue(thr, 0, 1));
Implement Object.is() and duk_samevalue() API call
8 years ago
return 1;
}
#endif
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_create(duk_hthread *thr) {
Small footprint optimizations for Object/Reflect
8 years ago
duk_hobject *proto;
first draft of Object.create()
12 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT_TOP(thr, 2);
first draft of Object.create()
12 years ago
Finalize buffer behavior when no bufobj support * Plain buffers still inherit from ArrayBuffer.prototype. * Plain buffers won&#39;t object coerce, so Object(plainBuffer) fails. * All buffer object related methods throw an error; their function bodies are essentially empty. Note that this includes bindings such as String.fromBuffer(), ArrayBuffer.allocPlain(), ArrayBuffer.plainOf(), and so on. In essence, you can index plain buffers in Ecmascript but the buffer values must be created via the C API. * Duktape custom bindings like Duktape.dec(&#39;hex&#39;, &#39;deadbeef&#39;) still work and produce plain buffers.
8 years ago
#if defined(DUK_USE_BUFFEROBJECT_SUPPORT)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_hbufobj_promote_plain(thr, 0);
Finalize buffer behavior when no bufobj support * Plain buffers still inherit from ArrayBuffer.prototype. * Plain buffers won&#39;t object coerce, so Object(plainBuffer) fails. * All buffer object related methods throw an error; their function bodies are essentially empty. Note that this includes bindings such as String.fromBuffer(), ArrayBuffer.allocPlain(), ArrayBuffer.plainOf(), and so on. In essence, you can index plain buffers in Ecmascript but the buffer values must be created via the C API. * Duktape custom bindings like Duktape.dec(&#39;hex&#39;, &#39;deadbeef&#39;) still work and produce plain buffers.
8 years ago
#endif
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
proto = duk_require_hobject_accept_mask(thr, 0, DUK_TYPE_MASK_NULL);
DUK_ASSERT(proto != NULL || duk_is_null(thr, 0));
first draft of Object.create()
12 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(void) duk_push_object_helper_proto(thr,
add duk_push_object_helper_proto() which takes an actual prototype pointer (not just a built-in index)
11 years ago
DUK_HOBJECT_FLAG_EXTENSIBLE |
Add DUK_HOBJECT_FLAG_FASTREFS for DECREF/marking When the flag is set, there is either no subclass C struct for the duk_hobject, or there is a subclass C struct but there are no references needing DECREF/marking in the struct. This allows DECREF and mark-and-sweep to handle duk_hobjects with less overhead for the common cases of plain objects and arrays (and some other less commonly collected structs like duk_hnatfunc). Also change Duktape.Thread.prototype internal class from Thread to Object: with the other changes internal code now assumes that if an object&#39;s class is Thread, it has the duk_hthread memory layout which wouldn&#39;t be the case for Duktape.Thread.prototype.
8 years ago
DUK_HOBJECT_FLAG_FASTREFS |
add duk_push_object_helper_proto() which takes an actual prototype pointer (not just a built-in index)
11 years ago
DUK_HOBJECT_CLASS_AS_FLAGS(DUK_HOBJECT_CLASS_OBJECT),
proto);
first draft of Object.create()
12 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (!duk_is_undefined(thr, 1)) {
first draft of Object.create()
12 years ago
/* [ O Properties obj ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_replace(thr, 0);
first draft of Object.create()
12 years ago
/* [ obj Properties ] */
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
/* Just call the "original" Object.defineProperties() to
* finish up.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_bi_object_constructor_define_properties(thr);
first draft of Object.create()
12 years ago
}
/* [ O Properties obj ] */
return 1;
a bunch of builtins
12 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_define_properties(duk_hthread *thr) {
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
duk_small_uint_t pass;
duk_uint_t defprop_flags;
duk_hobject *obj;
duk_idx_t idx_value;
duk_hobject *get;
duk_hobject *set;
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
/* Lightfunc and plain buffer handling by ToObject() coercion. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
obj = duk_require_hobject_promote_mask(thr, 0, DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
DUK_ASSERT(obj != NULL);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_to_object(thr, 1); /* properties object */
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
DUK_DDD(DUK_DDDPRINT("target=%!iT, properties=%!iT",
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(duk_tval *) duk_get_tval(thr, 0),
(duk_tval *) duk_get_tval(thr, 1)));
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
/*
* Two pass approach to processing the property descriptors.
* On first pass validate and normalize all descriptors before
* any changes are made to the target object. On second pass
* make the actual modifications to the target object.
*
* Right now we'll just use the same normalize/validate helper
* on both passes, ignoring its outputs on the first pass.
*/
for (pass = 0; pass < 2; pass++) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_set_top(thr, 2); /* -> [ hobject props ] */
duk_enum(thr, 1, DUK_ENUM_OWN_PROPERTIES_ONLY | DUK_ENUM_INCLUDE_SYMBOLS /*enum_flags*/);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
for (;;) {
duk_hstring *key;
/* [ hobject props enum(props) ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_set_top(thr, 3);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (!duk_next(thr, 2, 1 /*get_value*/)) {
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
break;
}
DUK_DDD(DUK_DDDPRINT("-> key=%!iT, desc=%!iT",
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(duk_tval *) duk_get_tval(thr, -2),
(duk_tval *) duk_get_tval(thr, -1)));
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
/* [ hobject props enum(props) key desc ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_hobject_prepare_property_descriptor(thr,
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
4 /*idx_desc*/,
&defprop_flags,
&idx_value,
&get,
&set);
Remove unnecesary pops from property prep helper
8 years ago
/* [ hobject props enum(props) key desc [multiple values] ] */
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
if (pass == 0) {
continue;
}
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
/* This allows symbols on purpose. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
key = duk_known_hstring(thr, 3);
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
DUK_ASSERT(key != NULL);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_hobject_define_property_helper(thr,
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
defprop_flags,
obj,
key,
idx_value,
get,
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
set,
1 /*throw_flag*/);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
}
}
/*
* Return target object
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_dup_0(thr);
Add duk_def_prop(), rework defineProperty() Add a C API binding for Object.defineProperty(): duk_def_prop(). In addition to Object.defineProperty() features, the API call provides a &#34;force&#34; flag which allows properties to be added to non-extensible objects and non-configurable properties to be changed (except virtual properties which are immutable). Because the name duk_def_prop() conflicts with internal calls, rename them from duk_def_prop*() to duk_xdef_prop*(). This rename also makes it clearer that the internal duk_xdef_prop*() calls have non-compliant, internal semantics. Also reimplement Object.defineProperty() and Object.defineProperties() (and duk_def_prop()) so that they share the same internal helpers, and there is no need for a temporary property descriptor object which is unnecessary churn. Detailed changes: - New helper to prepare (validate and normalize) property descriptors - New helper to implement Object.defineProperty() internals, leaving out validation of the property descriptor - Reimplement Object.defineProperty() using the new helpers - Reimplement Object.defineProperties() using the new helpers - Reimplement duk_define_property() using the new helpers, so that a temporary property descriptor object is no longer created - Add support for &#34;force&#34; flag to Object.defineProperty()
10 years ago
return 1;
a bunch of builtins
12 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_seal_freeze_shared(duk_hthread *thr) {
DUK_ASSERT_TOP(thr, 1);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_seal_freeze_raw(thr, 0, (duk_bool_t) duk_get_current_magic(thr) /*is_freeze*/);
implement seal(), freeze(), preventExtensions()
12 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
implement seal(), freeze(), preventExtensions()
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_is_sealed_frozen_shared(duk_hthread *thr) {
a bunch of builtins
12 years ago
duk_hobject *h;
Miscellaneous typing work here and there
11 years ago
duk_bool_t is_frozen;
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
duk_uint_t mask;
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
is_frozen = (duk_bool_t) duk_get_current_magic(thr);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
mask = duk_get_type_mask(thr, 0);
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
if (mask & (DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER)) {
DUK_ASSERT(is_frozen == 0 || is_frozen == 1);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_boolean(thr, (mask & DUK_TYPE_MASK_LIGHTFUNC) ?
Make plain buffers behave like ArrayBuffers Change handling of plain buffers so that they behave like ArrayBuffer instances to Ecmascript code, with limitations such as not being extensible and all properties being virtualized. This simplifies Ecmascript code as plain buffers are just lightweight ArrayBuffers (similarly to how lightfuncs appear as function objects). There are a lot of small changes in how the built-in objects and methods, and the C API deals with plain buffer values. Also make a few small changes to plain pointer and lightfunc handling to improve consistency with how plain buffers are now handled.
8 years ago
1 : /* lightfunc always frozen and sealed */
(is_frozen ^ 1)); /* buffer sealed but not frozen (index props writable) */
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
} else {
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015 Sections 19.1.2.12, 19.1.2.13: anything other than an object
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
* is considered to be already sealed and frozen.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h = duk_get_hobject(thr, 0);
duk_push_boolean(thr, (h == NULL) ||
duk_hobject_object_is_sealed_frozen_helper(thr, h, is_frozen /*is_frozen*/));
First round of lightfunc changes A lot of changes to add preliminary lightfunc support: * Add LIGHTFUNC tagged type to duk_tval.h and API. * Internal changes for preliminary to support lightfuncs in call handling and other operations (FIXMEs left in obvious places where support is still missing after this commit) * Preliminary Ecmascript and API testcases for lightfuncs Detailed notes: * Because magic is signed, reading it back involves sign extension which is quite verbose to do in C. Use macros for reading the magic value and other bit fields encoded in the flags. * Function.prototype.bind(): the &#39;length&#39; property of a bound function now comes out wrong. We could simply look up the virtual &#39;length&#39; property even if h_target is NULL: no extra code and binding is relatively rare in hot paths. Rewrite more cleanly in any case. * The use flag DUK_USE_LIGHTFUNC_BUILTINS controls the forced lightfunc conversion of built-ins. This results in non-compliant built-ins but significant memory savings in very memory poor environments. * Reject eval(), Thread.yield/resume as lightfuncs. These functions have current assertions that they must be called as fully fledged functions. * Lightfuncs are serialized like ordinary functions for JSON, JX, and JC by this diff. * Add &#39;magic&#39; to activation for lightfuncs. It will be needed for lightweight functions: we don&#39;t have the duk_tval related to the lightfunc, so we must copy the magic value to the activation when a call is made. * When lightfuncs are used as property lookup base values, continue property lookup from the Function.prototype object. This is necessary to allow e.g. ``func.call()`` and ``func.apply()`` to be used. * Call handling had to be reworked for lightfuncs, especially how bound function chains are handled. This is a relatively large change but is necessary to support lightweight functions properly in bound function resolution. The current solution is not ideal. The bytecode executor will first try an ecma-to-ecma call setup which resolves the bound function chain first. If the final, unbound function is not viable (a native function) the call setup returns with an error code. The caller will then perform a normal call. Although bound function resolution has already been done, the normal call handling code will re-do it (and detect there is nothing to do). This situation could be avoided by decoupling bound function handling and effective this binding computation from the actual call setup. The caller could then to do this prestep first, and only then decide whether to use an ecma-to-ecma call or an ordinary heavyweight call. Remove duk__find_nonbound_function as unused. * Use indirect magic to allow LIGHTFUNCs for Date. Most of the built-in functions not directly eligible as lightfuncs are the Date built-in methods, whose magic values contain too much information to fit into the 8-bit magic of a LIGHTFUNC value. To work around this, add an array (duk__date_magics[]) containing the actual control flags needed by the built-ins, and make the Date built-in magic value an index into this table. With this change Date built-ins are successfully converted to lightfuncs. Testcase fixes: - Whitespace fixes - Print error for indirect eval error to make diagnosis easier - Fix error string to match errmsg updated in this branch
11 years ago
}
a bunch of builtins
12 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_to_locale_string(duk_hthread *thr) {
DUK_ASSERT_TOP(thr, 0);
(void) duk_push_this_coercible_to_object(thr);
duk_get_prop_stridx_short(thr, 0, DUK_STRIDX_TO_STRING);
Unnecessary callable check, better push boolean
8 years ago
#if 0 /* This is mentioned explicitly in the E5.1 spec, but duk_call_method() checks for it in practice. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_require_callable(thr, 1);
Unnecessary callable check, better push boolean
8 years ago
#endif
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_dup_0(thr); /* -> [ O toString O ] */
duk_call_method(thr, 0); /* XXX: call method tail call? */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_value_of(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* For lightfuncs and plain buffers, returns Object() coerced. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(void) duk_push_this_coercible_to_object(thr);
a bunch of builtins
12 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_is_prototype_of(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_hobject *h_v;
duk_hobject *h_obj;
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT_TOP(thr, 1);
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h_v = duk_get_hobject(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (!h_v) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_false(thr); /* XXX: tail call: return duk_push_false(thr) */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 1;
}
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h_obj = duk_push_this_coercible_to_object(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_ASSERT(h_obj != NULL);
/* E5.1 Section 15.2.4.6, step 3.a, lookup proto once before compare.
* Prototype loops should cause an error to be thrown.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_boolean(thr, duk_hobject_prototype_chain_contains(thr, DUK_HOBJECT_GET_PROTOTYPE(thr->heap, h_v), h_obj, 0 /*ignore_loop*/));
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_has_own_property(duk_hthread *thr) {
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
return (duk_ret_t) duk_hobject_object_ownprop_helper(thr, 0 /*required_desc_flags*/);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_property_is_enumerable(duk_hthread *thr) {
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
return (duk_ret_t) duk_hobject_object_ownprop_helper(thr, DUK_PROPDESC_FLAG_ENUMERABLE /*required_desc_flags*/);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
#endif /* DUK_USE_OBJECT_BUILTIN */
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Comments and other trivia
8 years ago
/* Shared helper to implement Object.getPrototypeOf,
* Object.prototype.__proto__ getter, and Reflect.getPrototypeOf.
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
*
* http://www.ecma-international.org/ecma-262/6.0/index.html#sec-get-object.prototype.__proto__
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_getprototype_shared(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/*
* magic = 0: __proto__ getter
* magic = 1: Object.getPrototypeOf()
* magic = 2: Reflect.getPrototypeOf()
*/
duk_hobject *h;
duk_hobject *proto;
duk_tval *tv;
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
duk_int_t magic;
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
magic = duk_get_current_magic(thr);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
if (magic == 0) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT_TOP(thr, 0);
duk_push_this_coercible_to_object(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(duk_get_top(thr) >= 1);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
if (magic < 2) {
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015 Section 19.1.2.9, step 1 */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_to_object(thr, 0);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
tv = DUK_GET_TVAL_POSIDX(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
switch (DUK_TVAL_GET_TAG(tv)) {
case DUK_TAG_BUFFER:
Uint8Array plain buffer, remove most non-std props * Change plain buffers to inherit from Uint8Array. This affects a lot of small things like Object.prototype.toString() output, enumeration of plain buffers, etc. It also changes JSON serialization for plain buffers because the index properties are enumerable as with Uint8Array instances. * Disable JSON stringify fastpath for plain buffers for now so that the virtual index properties get serialized correctly. * Remove ArrayBuffer non-standard virtual properties. * Remove DataView non-standard virtual properties. * Move .byteLength, .byteOffset, .BYTES_PER_ELEMENT, and .buffer into inherited getters as required in ES6. However, the .length property remains a virtual own property for now (it too is an inherited getter in ES6). * Move ArrayBuffer.allocPlain() and ArrayBuffer.plainOf() to Uint8Array.allocPlain() and Uint8Array.plainOf() to match the semantics change for plain buffers. * Fix Node.js buffer .slice() behavior, the returned Node.js buffer would have ArrayBuffer.isView == 0 which doesn&#39;t match the revised Node.js behavior (Buffers being Uint8Array instances) * Reject ArrayBuffers with a view offset/length in Node.js Buffer .slice() rather than accept such ArrayBuffers without actually respecting the view offset/length. * Allow a plain buffer or a lightfunc as a constructor &#34;replacement object&#34; return value.
8 years ago
proto = thr->builtins[DUK_BIDX_UINT8ARRAY_PROTOTYPE];
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
break;
case DUK_TAG_LIGHTFUNC:
proto = thr->builtins[DUK_BIDX_FUNCTION_PROTOTYPE];
break;
case DUK_TAG_OBJECT:
h = DUK_TVAL_GET_OBJECT(tv);
proto = DUK_HOBJECT_GET_PROTOTYPE(thr->heap, h);
break;
default:
/* This implicitly handles CheckObjectCoercible() caused
* TypeError.
*/
DUK_DCERROR_TYPE_INVALID_ARGS(thr);
}
if (proto != NULL) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_hobject(thr, proto);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
} else {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_null(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* Shared helper to implement ES2015 Object.setPrototypeOf,
Comments and other trivia
8 years ago
* Object.prototype.__proto__ setter, and Reflect.setPrototypeOf.
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
*
* http://www.ecma-international.org/ecma-262/6.0/index.html#sec-get-object.prototype.__proto__
* http://www.ecma-international.org/ecma-262/6.0/index.html#sec-object.setprototypeof
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_setprototype_shared(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/*
* magic = 0: __proto__ setter
* magic = 1: Object.setPrototypeOf()
* magic = 2: Reflect.setPrototypeOf()
*/
duk_hobject *h_obj;
duk_hobject *h_new_proto;
duk_hobject *h_curr;
duk_ret_t ret_success = 1; /* retval for success path */
duk_uint_t mask;
duk_int_t magic;
Comments and other trivia
8 years ago
/* Preliminaries for __proto__ and setPrototypeOf (E6 19.1.2.18 steps 1-4). */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
magic = duk_get_current_magic(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (magic == 0) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_this_check_object_coercible(thr);
duk_insert(thr, 0);
if (!duk_check_type_mask(thr, 1, DUK_TYPE_MASK_NULL | DUK_TYPE_MASK_OBJECT)) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 0;
}
/* __proto__ setter returns 'undefined' on success unlike the
* setPrototypeOf() call which returns the target object.
*/
ret_success = 0;
} else {
if (magic == 1) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_require_object_coercible(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
} else {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_require_hobject_accept_mask(thr, 0,
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_TYPE_MASK_LIGHTFUNC |
DUK_TYPE_MASK_BUFFER);
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_require_type_mask(thr, 1, DUK_TYPE_MASK_NULL | DUK_TYPE_MASK_OBJECT);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h_new_proto = duk_get_hobject(thr, 1);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* h_new_proto may be NULL */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
mask = duk_get_type_mask(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (mask & (DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER)) {
duk_hobject *curr_proto;
curr_proto = thr->builtins[(mask & DUK_TYPE_MASK_LIGHTFUNC) ?
DUK_BIDX_FUNCTION_PROTOTYPE :
Uint8Array plain buffer, remove most non-std props * Change plain buffers to inherit from Uint8Array. This affects a lot of small things like Object.prototype.toString() output, enumeration of plain buffers, etc. It also changes JSON serialization for plain buffers because the index properties are enumerable as with Uint8Array instances. * Disable JSON stringify fastpath for plain buffers for now so that the virtual index properties get serialized correctly. * Remove ArrayBuffer non-standard virtual properties. * Remove DataView non-standard virtual properties. * Move .byteLength, .byteOffset, .BYTES_PER_ELEMENT, and .buffer into inherited getters as required in ES6. However, the .length property remains a virtual own property for now (it too is an inherited getter in ES6). * Move ArrayBuffer.allocPlain() and ArrayBuffer.plainOf() to Uint8Array.allocPlain() and Uint8Array.plainOf() to match the semantics change for plain buffers. * Fix Node.js buffer .slice() behavior, the returned Node.js buffer would have ArrayBuffer.isView == 0 which doesn&#39;t match the revised Node.js behavior (Buffers being Uint8Array instances) * Reject ArrayBuffers with a view offset/length in Node.js Buffer .slice() rather than accept such ArrayBuffers without actually respecting the view offset/length. * Allow a plain buffer or a lightfunc as a constructor &#34;replacement object&#34; return value.
8 years ago
DUK_BIDX_UINT8ARRAY_PROTOTYPE];
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (h_new_proto == curr_proto) {
goto skip;
}
goto fail_nonextensible;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h_obj = duk_get_hobject(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (h_obj == NULL) {
goto skip;
}
DUK_ASSERT(h_obj != NULL);
Comments and other trivia
8 years ago
/* [[SetPrototypeOf]] standard behavior, E6 9.1.2. */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* TODO: implement Proxy object support here */
if (h_new_proto == DUK_HOBJECT_GET_PROTOTYPE(thr->heap, h_obj)) {
goto skip;
}
if (!DUK_HOBJECT_HAS_EXTENSIBLE(h_obj)) {
goto fail_nonextensible;
}
for (h_curr = h_new_proto; h_curr != NULL; h_curr = DUK_HOBJECT_GET_PROTOTYPE(thr->heap, h_curr)) {
Comments and other trivia
8 years ago
/* Loop prevention. */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (h_curr == h_obj) {
goto fail_loop;
}
}
DUK_HOBJECT_SET_PROTOTYPE_UPDREF(thr, h_obj, h_new_proto);
/* fall thru */
skip:
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_set_top(thr, 1);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
if (magic == 2) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_true(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
return ret_success;
fail_nonextensible:
fail_loop:
if (magic != 2) {
DUK_DCERROR_TYPE_INVALID_ARGS(thr);
} else {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_false(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 1;
}
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_define_property(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/*
* magic = 0: Object.defineProperty()
* magic = 1: Reflect.defineProperty()
*/
duk_hobject *obj;
duk_hstring *key;
duk_hobject *get;
duk_hobject *set;
duk_idx_t idx_value;
duk_uint_t defprop_flags;
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
duk_small_uint_t magic;
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_bool_t throw_flag;
duk_bool_t ret;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(thr != NULL);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_DDD(DUK_DDDPRINT("Object.defineProperty(): ctx=%p obj=%!T key=%!T desc=%!T",
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(void *) thr,
(duk_tval *) duk_get_tval(thr, 0),
(duk_tval *) duk_get_tval(thr, 1),
(duk_tval *) duk_get_tval(thr, 2)));
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* [ obj key desc ] */
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
magic = (duk_small_uint_t) duk_get_current_magic(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* Lightfuncs are currently supported by coercing to a temporary
* Function object; changes will be allowed (the coerced value is
* extensible) but will be lost. Same for plain buffers.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
obj = duk_require_hobject_promote_mask(thr, 0, DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_ASSERT(obj != NULL);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
key = duk_to_property_key_hstring(thr, 1);
(void) duk_require_hobject(thr, 2);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_ASSERT(obj != NULL);
DUK_ASSERT(key != NULL);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT(duk_get_hobject(thr, 2) != NULL);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/*
Use &#39;ECMAScript&#39; spelling in src-input
7 years ago
* Validate and convert argument property descriptor (an ECMAScript
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
* object) into a set of defprop_flags and possibly property value,
* getter, and/or setter values on the value stack.
*
* Lightfunc set/get values are coerced to full Functions.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_hobject_prepare_property_descriptor(thr,
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
2 /*idx_desc*/,
&defprop_flags,
&idx_value,
&get,
&set);
/*
* Use Object.defineProperty() helper for the actual operation.
*/
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
DUK_ASSERT(magic == 0U || magic == 1U);
throw_flag = magic ^ 1U;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
ret = duk_hobject_define_property_helper(thr,
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
defprop_flags,
obj,
key,
idx_value,
get,
set,
throw_flag);
/* Ignore the normalize/validate helper outputs on the value stack,
* they're popped automatically.
*/
Some -Wsign-conversion fixes * Change duk_bool_to to duk_small_uint_t from duk_small_int_t. This may cause some sign warnings in calling code. * Reject attempt to unpack an array-like value whose length is 2G or over; previously was not checked explicitly, and the length was cast to duk_idx_t with a sign change and the unpack would then later fail. Now it fails with a clean RangeError. * Add wrap check for Node.js Buffer.concat(). * API DUK_TYPE_xxx, DUK_TYPE_MASK_xxx, flag constants etc are now unsigned.
7 years ago
if (magic == 0U) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* Object.defineProperty(): return target object. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_hobject(thr, obj);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
} else {
/* Reflect.defineProperty(): return success/fail. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_boolean(thr, ret);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_get_own_property_descriptor(duk_hthread *thr) {
DUK_ASSERT_TOP(thr, 2);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015 Section 19.1.2.6, step 1 */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (duk_get_current_magic(thr) == 0) {
duk_to_object(thr, 0);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
}
Add duk_get_prop_desc() API call
8 years ago
/* [ obj key ] */
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_hobject_object_get_own_property_descriptor(thr, -2);
Add duk_get_prop_desc() API call
8 years ago
return 1;
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_is_extensible(duk_hthread *thr) {
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
/*
* magic = 0: Object.isExtensible()
* magic = 1: Reflect.isExtensible()
*/
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_hobject *h;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (duk_get_current_magic(thr) == 0) {
h = duk_get_hobject(thr, 0);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
} else {
/* Reflect.isExtensible(): throw if non-object, but we accept lightfuncs
* and plain buffers here because they pretend to be objects.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h = duk_require_hobject_accept_mask(thr, 0, DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_boolean(thr, (h != NULL) && DUK_HOBJECT_HAS_EXTENSIBLE(h));
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
return 1;
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
/* Shared helper for various key/symbol listings, magic:
* 0=Object.keys()
* 1=Object.getOwnPropertyNames(),
* 2=Object.getOwnPropertySymbols(),
* 3=Reflect.ownKeys()
*/
DUK_LOCAL const duk_small_uint_t duk__object_keys_enum_flags[4] = {
/* Object.keys() */
DUK_ENUM_OWN_PROPERTIES_ONLY |
DUK_ENUM_NO_PROXY_BEHAVIOR,
/* Object.getOwnPropertyNames() */
DUK_ENUM_INCLUDE_NONENUMERABLE |
DUK_ENUM_OWN_PROPERTIES_ONLY |
DUK_ENUM_NO_PROXY_BEHAVIOR,
/* Object.getOwnPropertySymbols() */
DUK_ENUM_INCLUDE_SYMBOLS |
DUK_ENUM_OWN_PROPERTIES_ONLY |
DUK_ENUM_EXCLUDE_STRINGS |
DUK_ENUM_INCLUDE_NONENUMERABLE |
DUK_ENUM_NO_PROXY_BEHAVIOR,
/* Reflect.ownKeys() */
DUK_ENUM_INCLUDE_SYMBOLS |
DUK_ENUM_OWN_PROPERTIES_ONLY |
DUK_ENUM_INCLUDE_NONENUMERABLE |
DUK_ENUM_NO_PROXY_BEHAVIOR
};
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_keys_shared(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_hobject *obj;
#if defined(DUK_USE_ES6_PROXY)
duk_hobject *h_proxy_target;
duk_hobject *h_proxy_handler;
duk_hobject *h_trap_result;
#endif
duk_small_uint_t enum_flags;
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
duk_int_t magic;
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT_TOP(thr, 1);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
magic = duk_get_current_magic(thr);
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
if (magic == 3) {
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015 Section 26.1.11 requires a TypeError for non-objects. Lightfuncs
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
* and plain buffers pretend to be objects, so accept those too.
*/
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
obj = duk_require_hobject_promote_mask(thr, 0, DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
} else {
Source ES6/7 -&gt; ES2015/ES2016 renames
8 years ago
/* ES2015: ToObject coerce. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
obj = duk_to_hobject(thr, 0);
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
}
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_ASSERT(obj != NULL);
DUK_UNREF(obj);
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
/* XXX: proxy chains */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
#if defined(DUK_USE_ES6_PROXY)
Use &#39;ownKeys&#39; trap for for-in (ES7), enum check * Remove &#39;enumerate&#39; trap. * Use &#39;ownKeys&#39; trap for &#34;for-in&#34; too, as specified in ES7. * Add enumerability check for &#39;ownKeys&#39; result when used in for-in or Object.keys(). Because there&#39;s no support for &#39;getOwnPropertyDescriptor&#39; trap yet, the check will always operate directly on the target object.
8 years ago
/* XXX: better sharing of code between proxy target call sites */
Add duk_hproxy internal struct
8 years ago
if (DUK_LIKELY(!duk_hobject_proxy_check(obj,
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
&h_proxy_target,
&h_proxy_handler))) {
goto skip_proxy;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_hobject(thr, h_proxy_handler);
if (!duk_get_prop_stridx_short(thr, -1, DUK_STRIDX_OWN_KEYS)) {
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
/* Careful with reachability here: don't pop 'obj' before pushing
* proxy target.
*/
DUK_DDD(DUK_DDDPRINT("no ownKeys trap, get keys of target instead"));
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_pop_2(thr);
duk_push_hobject(thr, h_proxy_target);
duk_replace(thr, 0);
DUK_ASSERT_TOP(thr, 1);
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
goto skip_proxy;
}
/* [ obj handler trap ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_insert(thr, -2);
duk_push_hobject(thr, h_proxy_target); /* -> [ obj trap handler target ] */
duk_call_method(thr, 1 /*nargs*/); /* -> [ obj trap_result ] */
h_trap_result = duk_require_hobject(thr, -1);
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
DUK_UNREF(h_trap_result);
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
magic = duk_get_current_magic(thr);
Fix a few compile warnings * Clang unreachable code warnings * Assert unsigned &gt;= 0 comparison warnings * MSVC duk_size_t -&gt; duk_uint_t cast * Pointer-to-integer cast warning when sizes differ, use DUK_MEMCPY() which works correctly with strict aliasing (since char accesses always alias), however this causes a clang sizeof() unreachable code warning
8 years ago
DUK_ASSERT(magic >= 0 && magic < (duk_int_t) (sizeof(duk__object_keys_enum_flags) / sizeof(duk_small_uint_t)));
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
enum_flags = duk__object_keys_enum_flags[magic];
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_proxy_ownkeys_postprocess(thr, h_proxy_target, enum_flags);
add ownKeys proxy trap, update Object.keys() and Object.getOwnPropertyNames() to use it (combining them into a shared helper in the process), make Proxy extensible
11 years ago
return 1;
skip_proxy:
#endif /* DUK_USE_ES6_PROXY */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ASSERT_TOP(thr, 1);
magic = duk_get_current_magic(thr);
Fix a few compile warnings * Clang unreachable code warnings * Assert unsigned &gt;= 0 comparison warnings * MSVC duk_size_t -&gt; duk_uint_t cast * Pointer-to-integer cast warning when sizes differ, use DUK_MEMCPY() which works correctly with strict aliasing (since char accesses always alias), however this causes a clang sizeof() unreachable code warning
8 years ago
DUK_ASSERT(magic >= 0 && magic < (duk_int_t) (sizeof(duk__object_keys_enum_flags) / sizeof(duk_small_uint_t)));
Add initial, minimal ES6 Symbol support * Strings with 0xFF byte prefix are considered special symbols: they have typeof &#34;symbol&#34; but still mostly behave as strings (e.g. allow ToString) so that existing code dealing with internal keys, especially inside Duktape, can work with fewer changes. * Strings with 0x80 byte prefix are global symbols, e.g. Symbol.for(&#39;foo&#39;) creates the byte representatio: 0x80 &#34;foo&#34; * Strings with 0x81 byte prefix are unique symbols; the 0x81 byte is followed by the Symbol description, and an internal string component ensuring uniqueness is separated by a 0xFF byte (which can never appear anywhere in an extended UTF-8 string). The unique suffix is up to Duktape internals, currently two 32-bit counters are used. For example: 0x81 &#34;mySymbol&#34; 0xFF &#34;0-17&#34;. * Well-known symbols use the 0x81 prefix but lack a unique suffix, so their format is 0x81 &lt;description&gt; 0xFF. * ES6 distinguishes between an undefined symbol description and an empty string symbol description. This distinction is not currently visible via Ecmascript bindings but may be visible in the future. Append an extra 0xFF to the unique suffix when the description is undefined, i.e. 0x81 0xFF &lt;unique suffix&gt; 0xFF.
8 years ago
enum_flags = duk__object_keys_enum_flags[magic];
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
return duk_hobject_get_enumerated_keys(thr, enum_flags);
a bunch of builtins
12 years ago
}
Per function guards to move functions more easily
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
a bunch of builtins
12 years ago
Per function guards to move functions more easily
8 years ago
#if defined(DUK_USE_OBJECT_BUILTIN) || defined(DUK_USE_REFLECT_BUILTIN)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_constructor_prevent_extensions(duk_hthread *thr) {
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/*
* magic = 0: Object.preventExtensions()
* magic = 1: Reflect.preventExtensions()
*/
a bunch of builtins
12 years ago
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_hobject *h;
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
duk_uint_t mask;
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_int_t magic;
cleanup DUK_ASSERT(duk_get_top...) assertions to DUK_ASSERT_TOP(); implement Object.prototype.isPrototypeOf
12 years ago
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
magic = duk_get_current_magic(thr);
cleanup DUK_ASSERT(duk_get_top...) assertions to DUK_ASSERT_TOP(); implement Object.prototype.isPrototypeOf
12 years ago
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
/* Silent success for lightfuncs and plain buffers always. */
mask = DUK_TYPE_MASK_LIGHTFUNC | DUK_TYPE_MASK_BUFFER;
/* Object.preventExtensions() silent success for non-object. */
if (magic == 0) {
mask |= DUK_TYPE_MASK_UNDEFINED |
DUK_TYPE_MASK_NULL |
DUK_TYPE_MASK_BOOLEAN |
DUK_TYPE_MASK_NUMBER |
DUK_TYPE_MASK_STRING |
DUK_TYPE_MASK_POINTER;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
if (duk_check_type_mask(thr, 0, mask)) {
Align Object.keys() etc. arg policy with ES6 In ES6, Object.keys(), Object.freeze(), Object.isExtensible(), etc. no longer reject non-object values with a TypeError, but instead either ToObject coerce them or treat them as non-extensible objects with no own properties, depending on the call.
8 years ago
/* Not an object, already non-extensible so always success. */
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
goto done;
cleanup DUK_ASSERT(duk_get_top...) assertions to DUK_ASSERT_TOP(); implement Object.prototype.isPrototypeOf
12 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
h = duk_require_hobject(thr, 0);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_ASSERT(h != NULL);
cleanup DUK_ASSERT(duk_get_top...) assertions to DUK_ASSERT_TOP(); implement Object.prototype.isPrototypeOf
12 years ago
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
DUK_HOBJECT_CLEAR_EXTENSIBLE(h);
cleanup DUK_ASSERT(duk_get_top...) assertions to DUK_ASSERT_TOP(); implement Object.prototype.isPrototypeOf
12 years ago
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
/* A non-extensible object cannot gain any more properties,
* so this is a good time to compact.
Prototype loop fix for error augmentation Add an ignore_loop argument to duk_hobject_prototype_chain_contains() to support this behavior. It depends on the context whether a prototype loop should cause an error to be thrown or not.
10 years ago
*/
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
duk_hobject_compact_props(thr, h);
refactor Object hasOwnProperty() and propertyIsEnumerable() to use duk_hobject_props.c helper directly
12 years ago
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
done:
if (magic == 1) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_true(thr);
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
}
return 1;
a bunch of builtins
12 years ago
}
Add ES6 Reflect built-in object All Reflect functions specified in ECMAScript 2016 are implemented, and most share Duktape/C helpers with their ES5 twins from Object. * Reflect.apply() * Reflect.construct() * Reflect.defineProperty() * Reflect.deleteProperty() * Reflect.get() * Reflect.getOwnPropertyDescriptor() * Reflect.getPrototypeOf() * Reflect.has() * Reflect.isExtensible() * Reflect.ownKeys() * Reflect.preventExtensions() * Reflect.set() * Reflect.setPrototypeOf() Presence of the Reflect object is controlled by DUK_USE_REFLECT_BUILTIN and enabled by default in the standard configuration. note: Reflect.enumerate() was retroactively removed in ES7, so it will not be implemented in Duktape.
8 years ago
#endif /* DUK_USE_OBJECT_BUILTIN || DUK_USE_REFLECT_BUILTIN */
Add __defineGetter__() and __defineSetter__()
8 years ago
/*
Add __lookupGetter__ and __lookupSetter__
8 years ago
* __defineGetter__, __defineSetter__, __lookupGetter__, __lookupSetter__
Add __defineGetter__() and __defineSetter__()
8 years ago
*/
#if defined(DUK_USE_ES8)
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_defineaccessor(duk_hthread *thr) {
duk_push_this(thr);
duk_insert(thr, 0);
duk_to_object(thr, 0);
duk_require_callable(thr, 2);
Add __defineGetter__() and __defineSetter__()
8 years ago
/* [ ToObject(this) key getter/setter ] */
/* ToPropertyKey() coercion is not needed, duk_def_prop() does it. */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_def_prop(thr, 0, DUK_DEFPROP_SET_ENUMERABLE |
Add __defineGetter__() and __defineSetter__()
8 years ago
DUK_DEFPROP_SET_CONFIGURABLE |
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
(duk_get_current_magic(thr) ? DUK_DEFPROP_HAVE_SETTER : DUK_DEFPROP_HAVE_GETTER));
Add __defineGetter__() and __defineSetter__()
8 years ago
return 0;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_INTERNAL duk_ret_t duk_bi_object_prototype_lookupaccessor(duk_hthread *thr) {
Add __lookupGetter__ and __lookupSetter__
8 years ago
duk_uint_t sanity;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_push_this(thr);
duk_to_object(thr, -1);
Add __lookupGetter__ and __lookupSetter__
8 years ago
/* XXX: Prototype walk (with sanity) should be a core property
* operation, could add a flag to e.g. duk_get_prop_desc().
*/
/* ToPropertyKey() coercion is not needed, duk_get_prop_desc() does it. */
sanity = DUK_HOBJECT_PROTOTYPE_CHAIN_SANITY;
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
while (!duk_is_undefined(thr, -1)) {
Add __lookupGetter__ and __lookupSetter__
8 years ago
/* [ key obj ] */
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_dup(thr, 0);
duk_get_prop_desc(thr, 1, 0 /*flags*/);
if (!duk_is_undefined(thr, -1)) {
duk_get_prop_stridx(thr, -1, (duk_get_current_magic(thr) != 0 ? DUK_STRIDX_SET : DUK_STRIDX_GET));
Add __lookupGetter__ and __lookupSetter__
8 years ago
return 1;
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_pop(thr);
Add __lookupGetter__ and __lookupSetter__
8 years ago
if (DUK_UNLIKELY(sanity-- == 0)) {
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
DUK_ERROR_RANGE(thr, DUK_STR_PROTOTYPE_CHAIN_LIMIT);
More DUK_WO_NORETURN() fixes These call sites didn&#39;t generate warnings but changed to be consistent with the other call sites: DUK_ERROR*() always followed by DUK_WO_NORETURN().
7 years ago
DUK_WO_NORETURN(return 0;);
Add __lookupGetter__ and __lookupSetter__
8 years ago
}
Use duk_hthread, not duk_context in internals Both duk_hthread and duk_context typedefs resolve to struct duk_hthread internally. In external API duk_context resolves to struct duk_hthread which is intentionally left undefined as the struct itself is not dereferenced. Change internal code to use duk_hthread exclusively which removes unnecessary and awkward thr &lt;-&gt; ctx casts from internals. The basic guidelines are: * Public API uses duk_context in prototype declarations. The intent is to hide the internal type, and there&#39;s already a wide dependency on the type name. * All internal code, both declarations and definitions, use duk_hthread exclusively. This is done even for API functions, i.e. an API function declared as &#34;void duk_foo(duk_context *ctx);&#34; is then defined as &#34;void duk_foo(duk_hthread *thr);&#34;.
7 years ago
duk_get_prototype(thr, -1);
duk_remove(thr, -2);
Add __lookupGetter__ and __lookupSetter__
8 years ago
}
return 1;
}
Add __defineGetter__() and __defineSetter__()
8 years ago
#endif /* DUK_USE_ES8 */