Hi,
Filip Pizlo <mailto:[email protected]>
August 28, 2013 11:01 PM
Here's the part that gets me, though: what is the value of disallowing
named properties on typed arrays? Who does this help?
You've heard about symmetry with struct types (ES6), right? Those do not
want expandos. We could break symmetry but at some cost. Too small to
worry about? Outweighed by benefits?
Sfink's point about structured clone is good, except he wrote
"structured clone" and then angels cried... tears of blood.
I don't quite buy that this helps users; most of the objects in your
program are going to allow custom properties to be added at any point.
That's kind of the whole point of programming in a dynamic language.
So having one type where it's disallowed doesn't help to clarify
thinking.
There are other such types a-coming :-).
I also don't buy that it makes anything more efficient. We only incur
overhead from named properties if you actually add named properties to
a typed array, and in that case we incur roughly the overhead you'd
expect (those named properties are a touch slower than named
properties on normal objects, and you obviously need to allocate some
extra space to store those named properties).
Honest q: couldn't you squeeze one more word out if JSC typed arrays
were non-extensible?
/be
-Filip
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Oliver Hunt <mailto:[email protected]>
August 27, 2013 9:35 AM
Existing types with magic index properties (other than Array) just
drop numeric expandos on the floor so it's logically a no-op. Unless
there was a numeric accessor on the prototype (which non-extensibility
does not save you from).
My complaint is that this appears to be removing functionality that
has been present in the majority of shipping TA implementations,
assuming from LH's comment that Chakra supports expandos.
--Oliver
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Domenic Denicola <mailto:[email protected]>
August 27, 2013 9:26 AM
I am not aware of all the nuances of the discussion, but as a
developer I would find the behavior for numeric expandos confusing.
For a typed array of length 1024, setting `ta[1023]` would do
something completely different from setting `ta[1024]`. Unlike normal
arrays, setting `ta[1024]` would not change `ta.length`, and
presumably `ta[1024]` would not be exposed by the various iteration
facilities.
I would much rather received a loud error (in strict mode), which will
either alert me to my code being weird, or possibly to my code
committing an off-by-one error.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Oliver Hunt <mailto:[email protected]>
August 27, 2013 9:18 AM
The curent argument for non-extensibility seems to be mozilla doesn't
support them. It sounds like all other engines do.
There are plenty of reasons developers may want expandos - they're
generally useful for holding different kinds of metadata. By
requiring a separate object to hold that information we're merely
making a developer's life harder. This is also inconsistent with all
other magically-indexable types in ES and the DOM.
I'm also not sure what the performance gains of inextensibility are,
if DH could expand it would be greatly appreciated.
--Oliver
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
Allen Wirfs-Brock <mailto:[email protected]>
August 27, 2013 9:04 AM
see meeting notes
https://github.com/rwaldron/tc39-notes/blob/master/es6/2013-07/july-24.md#54-are-typedarray-insances-born-non-extensible
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
