To me the compelling argument against using encapsulation instead of extensibility is that it breaks compatibility with existing JS code. Once you encapsulate an array, the encapsulated object no longer acts like an array and you can't use it in contexts where a normal array is expected. The ability to do python style 'quacks like an array' duck typing simply doesn't exist for arrays in JS.
This is a huge problem for JSIL interop - I can't preserve type information for arrays, or expose other array features, without either breaking interop with pure JS or otherwise eating some enormous perf hit (proxies, spidermonkey's deopt from named slots on arrays, etc). Baking this limitation into the spec for typed arrays is kind of awful, but I can understand if it's absolutely necessary... Maybe WeakMap is the right solution for this? I can't remember what the performance consequences are for that use case. (Can you use an Array as a weakmap key? I forget, since it's an object-like type but it has special properties...) Note that I'm not arguing for array subclassing here, just the ability to 'bless' an array instance with extra information. Such use cases are no doubt fairly rare, even if it's possible to come up with a handful of them. I assume StructType and ArrayType will address a lot of this, but I'm not sure how I feel about having to wait for those features when (were typed arrays specced to allow named expandos) you could do this stuff in a mostly cross-browser way and ship it right now. (WeakMap fails this test since IIRC it's still only available in Firefox. :/ I love it and wish I could use it in the wild!) On Tue, Aug 27, 2013 at 3:49 PM, David Herman <[email protected]> wrote: > On Aug 27, 2013, at 9:47 AM, Filip Pizlo <[email protected]> wrote: > > > I do. Placing named properties on arrays makes sense. Consider a matrix > implemented as a Float32Array, with named properties telling you the > numRows and numCols. Just one example. > > There are of course other ways to achieve this that don't involve patching > the array object, such as building a data abstraction for matrices that > has-a Float32Array, or creating a new array type with additional methods: > > var Matrix = new ArrayType(float32); > Matrix.prototype.numRows = function() { ... } > // or > Object.defineProperty(Matrix.prototype, { get: function() { ... }, ... > }); > > >> TA instances having no indexed expandos but allowing named ones is > weird. Better to be consistent to users > > > > Consistency would imply doing what other indexed types do. > > Consistency arguments won't get you very far. The indexed properties of > typed arrays by design act very differently from other indexed types. > That's their whole reason for existence. > > And the other consistency dimension is between array types and struct > types. Is anyone arguing that structs should also have expandos? > > Dave > > _______________________________________________ > 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
