for what `typeof` *means* to people) and whether `uvalue.foo` works
via a wrapper or some other mechanism.
Niko
On Wed, Apr 02, 2014 at 05:01:10PM +0200, Andreas Rossberg wrote:
> On 2 April 2014 16:32, Niko Matsakis wrote:
> > I just wanted to let people on es-discuss know
I just wanted to let people on es-discuss know about two of my recent
blog posts concerning typed objects. The first is a kind of status
report:
http://smallcultfollowing.com/babysteps/blog/2014/04/01/typed-objects-status-report/
and the second details some (preliminary) thoughts on how one could
On Fri, Dec 06, 2013 at 01:20:20PM -0800, Allen Wirfs-Brock wrote:
> Does the surprise then lead you to deeper understanding of essential
> differences?
I don't disagree with you that there are potential differences, but I
do disagree that these differences are *essential*. It seems to me
that th
On Fri, Dec 06, 2013 at 09:08:09AM -0800, Allen Wirfs-Brock wrote:
> 1) For the map method, the source and destination collection are the
> same object ...
How are the source and destination collection the same in the case of
map()? Perhaps you meant that they are the same *type of collection*?
>
data_parallelism
On Thu, Dec 05, 2013 at 10:13:58PM -0500, Niko Matsakis wrote:
> The ES6 draft specifies that `map()`, when applied to a typed array,
> yields another instance of that same type. For converting between
> array types, the `from()` method is added:
>
>
The ES6 draft specifies that `map()`, when applied to a typed array,
yields another instance of that same type. For converting between
array types, the `from()` method is added:
var f1 = new Float32Array();
...
var f2 = f1.map(x => x * 2); // Yields Float32Array
var i1 = Int32Array
On Mon, Nov 18, 2013 at 11:46:30AM -0800, Andrea Giammarchi wrote:
> if it's about experimenting then `with(TypedObject) {}` would do :P
>
> Any chance there will be a way to bypass most of the stuff for production?
Sorry I don't understand the question.
Niko
___
On Sun, Nov 17, 2013 at 02:04:57PM +0100, Till Schneidereit wrote:
> The strawman at [1] is fairly close to what's going to end up in the spec,
> content-wise. Additionally, the implementation in SpiderMonkey is pretty
> complete by now, and there are lots of tests[2].
Indeed, it's approaching ful
On Sun, Nov 17, 2013 at 10:42:16PM +0100, Dmitry Lomov wrote:
> Typed Objects polyfill lives here: https://github.com/dherman/structs.js
> Dave and I work on it, current status is pretty close to strawman minus
> handles and cursors (which are a bit controversial at this point and as far
> as I und
On Mon, Nov 18, 2013 at 03:07:28AM -0800, K. Gadd wrote:
> If DataView were to also get optimized in SpiderMonkey, that would release
> a lot of the pressure (use-case wise) for Typed Objects to expose
> fine-grained control over alignment/padding and it would make it less
> immediately necessary f
On Thu, Sep 05, 2013 at 09:15:11AM +0200, Andreas Rossberg wrote:
> Maybe it actually _is_ worth considering a different equality
> semantics for structs and typed arrays. In essence, they are a kind of
> super-fat pointer, and we could give them the usual notion of (fat)
> pointer equality. That i
On Wed, Sep 04, 2013 at 02:41:24PM -0700, Brendan Eich wrote:
> Both adds up to two, not one, so the counterargument is odd beats
> odder, and prohibiting expandos keeps the oddness down to == and
> nothing else.
I just want to agree with this. I think the behavior of `==` is
unfortunate, but much
On Wed, Sep 04, 2013 at 12:38:39PM -0700, Filip Pizlo wrote:
> The reason why I'm OK with the more complex story is that we already
> have that story for '=='. To me, named object properties are
> analogous to being able to identify whether you have the same object
> or a different object: both ar
I think Filip is right that given sufficient cleverness extensible
properties for typed objects can be implemented efficiently. The real
question is what the behavior SHOULD be. As others have pointed out,
we are not forced to support extensible properties for web compat
reasons.
I also think it i
14 matches
Mail list logo
