On Tue, Aug 27, 2013 at 4:14 PM, K. Gadd <[email protected]> wrote: > 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? >
Yes. > I forget, since it's an object-like type but it has special properties...) > A weakmap key has an unforgeable per-act-of-creation identity, which is the only requirement. Arrays pass. Strings fail. Interestingly, if we provide a system-wide interning table from strings to symbols, then internable symbols fail. Else, unique symbols pass, but have all the problems previously enumerated. > > 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 > > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
