Array.create and Function.create
An array with no prototype wouldn't have any of the iteration methods on it; a function with no prototype wouldn't have .call/.bind/.apply - length and name are own properties of functions, and length is an own property of an array, so you'd get those regardless.
(Array.from({ length: 1000 })
already creates an array of length 1000
without holes, fwiw)
An array with no prototype wouldn't have any of the iteration methods on
it...
Yes, that is what is intended with this, similar to an Object.create(null) object with number-ed keys.
Alternatively one could look at the objects created from this to be the "bare-bones" structure around these data-structures.
That is the in-existence of prototypes and own properties like "length" makes it clear that these "flat" objects are intended as author managed objects.
There are is no visible default prototype or own properties because the author will create, expose and managed these for the data-structure explicitly if need be or more commonly choose to not expose the data-structure at all and use these for low-level internal book keeping for other abstractions.
This would create a new ceiling(or ground-level) for how "low-level" one could go with JavaScript if these where part for the language and as a secondary consequence allow engines to make stronger assumptions with to operations on these structs.
Why would this be better than const a = []; Object.setPrototypeOf(a, null)
?
Why would this be better than `const a = []; Object.setPrototypeOf(a,
null)`?
In that example "a" value would still have "own" properties like length.
a = Array.create(null, 10)
Wouldn't have any own or prototype properties by design; It is mean to be "bare-bones" or as close to a C-like:
a = malloc(sizeof(void*)*10)
as JavaScript could potentially get.
If you don't want the iterable features neither the own properties,
what're the benefits over a object indexed by numbers const o = Object.create(null); o[0] = 12; ...
?
About the other function proprosal (Function.create
) I don't see any
benefits in day to day use having a function without prototype
If you are interested in a performatic barebones fixed-sized arrays (like your C example) you should read about ArrayBuffers and Typed Array views1. Actually it is the closest to your example as Javascript could potentially get.
Em qui, 10 de jan de 2019 às 07:35, Sultan <thysultan at gmail.com> escreveu:
On Thu, Jan 10, 2019 at 1:54 PM Augusto Moura <augusto.borgesm at gmail.com> wrote:
If you don't want the iterable features neither the own properties, what're the benefits over a object indexed by numbers
const o = Object.create(null); o[0] = 12; ...
?
Exactly.
And re functions, using them as state containers without their usual
features seems like a bad idea^H^H^H^H^H^H^H^H edge case best handled
by setPrototypeOf
and delete
. :-)
-- T.J. Crowder
Sorry if I was unclear; it's impossible to have an array without a
.length
own property, and there'd be no way to get the length or iterate
over it if you did. I'm also not clear on why you'd want to store named
properties on an array, especially if you can't iterate it because it
doesn't have a length?
what're the benefits over a object indexed by numbers `const o =
Object.create(null); o[0] = 12; ...`?
Better "optimisable" heuristics in a similar vain to TypedArrays
. Most
engines have perf cliffs with indexed objects after a certain threshold,
Memory: at some point indexed objects have to grow by some factor(* N of the current size) until it reaches and exceeds your desired size resulting in more memory use that you bargained for or at some point the engine could downgrade it to dictionary-mode for any one reason.
It is a fickle round to cross when you want predictable throughput performance, TypedArrays afford this, but they are not generic(support any value).
About the other function proposal (
Function.create
) I don't see any
benefits in day to day use having a function without prototype
Both the Array.create and Function.create are not meant as day-to-day data-structures. They are meant as low-level building blocks for abstraction that might be used on a day-to-day, abstractions that wish to guarantee better predictable performance.
and there'd be no way to get the length or iterate over it if you did.
You don't need a length property to iterate the array if you own and manage the data-strucure:
Exhibit A: var len = 10 var arr = Array.create(null, len) for (var i = 0; i < len; i++) arr[i]
Exhibit B: (tuple)
var arr = Array.create(null, 2) arr[0] = 'a' arr[1] = 'b' return a
In both examples you don't need a length property to access/visit all the elements in the array given they are both statically known at creation time.
Fwiw I'd absolutely love a way to create function objects that inherit from an existing custom object.
You can already do that - function f() {} Object.setPrototypeOf(f, customObject)
Identical to Object.create but for Arrays and Functions.
This method will allow you to create arrays with no prototype.
This would allow authors the ability to use array objects as state containers without the need to resort to index-based objects with
Object.create(null, length)
When you want to both use an array-like struct as both a property and index-able map.
A side-effect of this would afford engines a strong heuristic for avoiding holey-array look-ups operations when there's no prototype to walk.
For example the following would create an array with a length of 1000 without "holes".
const arr = Array.create(null, 1000)
In addition this could also apply to functions with
Function.create(null, () => {})
When you want to use functions as state-containers but don't want any of the implicit properties(length, name) etc.