Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 4:42 PM, David Herman wrote: > On Aug 30, 2013, at 4:20 PM, Filip Pizlo wrote: > >> This is the kind of weirdness that I hope struct types *don't* have, if >> their alleged purpose is to help people optimize their code. > > This is a great point, thanks. On the one hand,

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 4:20 PM, Filip Pizlo wrote: > This is the kind of weirdness that I hope struct types *don't* have, if their > alleged purpose is to help people optimize their code. This is a great point, thanks. On the one hand, I concluded long ago the exposure of the buffer seems like so

Re: Request license change

Musical Notation wrote: However, I think that the restriction comes from the greed of Ecma International. If this is the case, protest them and tell them we need a freely licensed ECMAScript specification! I don't think the issue is "greed" -- Ecma doesn't make big bucks off spec licensing or

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 4:03 PM, David Herman wrote: > On Aug 30, 2013, at 3:54 PM, Filip Pizlo wrote: > >> Yup, that's what I was concerned about. And reading over the spec I agree. >> But just for sanity, we're guaranteeing this because you cannot create a >> struct type instance by pointing

Propose license change

To solve this problem, I think that the standard should be a WHATWG standard. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 3:54 PM, Filip Pizlo wrote: > Yup, that's what I was concerned about. And reading over the spec I agree. > But just for sanity, we're guaranteeing this because you cannot create a > struct type instance by pointing into an arbitrary offset of a buffer - you > can only ins

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 3:46 PM, David Herman wrote: > On Aug 30, 2013, at 12:46 PM, Filip Pizlo wrote: > >> OK - by "sanepants" do you mean that there is no weirdo aliasing? Going >> back to my example of field 'a' aliasing field 'b' - is it possible? > > There is plenty of aliasing possible,

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 3:46 PM, David Herman wrote: > E.g., if I have a struct type > >var T = new StructType({ a: t1, b: t2, ... }); > > then for any given instance x of T, I know for sure that x.a and x.b do not > alias the same storage. (Except, of course, if t1 and t2 are pointer types l

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 12:46 PM, Filip Pizlo wrote: > OK - by "sanepants" do you mean that there is no weirdo aliasing? Going back > to my example of field 'a' aliasing field 'b' - is it possible? There is plenty of aliasing possible, but I'm trying to understand what you mean specifically by "w

Re: Should the "length" property of bound functions be configurable

On Fri, Aug 30, 2013 at 2:39 PM, Brandon Benvie wrote: > Part of the function name proposal submitted would make "name" writable > but not configurable, which is the inverse of the current spec for "length" > being configurable but not writable. Seems there needs to be some > discussion on what a

Re: Should the "length" property of bound functions be configurable

The thing that worries me about configurability is that it allows something to become an accessor. I was following the path of "prototype" when deciding on non-configurability for "name". Essentially: preventing arbitrary code from executing when accessing this thing. I'm not married to this re

Re: Non-extensibility of Typed Arrays

Hi, Filip Pizlo 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 bre

Re: Should the "length" property of bound functions be configurable

Part of the function name proposal submitted would make "name" writable but not configurable, which is the inverse of the current spec for "length" being configurable but not writable. Seems there needs to be some discussion on what attributes should be where. On Aug 30, 2013, at 7:36 PM, "Mark

Re: Non-extensibility of Typed Arrays

Filip Pizlo wrote: Sometimes you want a product of different types, not a vector of same-typed elements. Typed arrays were designed so you would alias two views, crazypants. Structs put on sanepants. Just making sure the use-case has clear motivation here. OK - by "sanepants" do you mean that

Re: Should the "length" property of bound functions be configurable

Mark and I discussed this privately a while back. We would rather use the same attribute pair for both. Is non-writable configurable ok? I argued that for name it is onerous to require Object.defineProperty calls, e.g., from Cappuccino when compiling Objective-J into JS, to fix up every functio

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 12:31 PM, Brendan Eich wrote: > Thanks for the reply, I'll let SM and V8 peeps speak for themselves (they > retired my SM number ;-). >> Filip Pizlo >> August 30, 2013 10:41 AM >> >> On Aug 30, 2013, at 9:28 AM, Brendan Eich >

Re: Non-extensibility of Typed Arrays

Thanks for the reply, I'll let SM and V8 peeps speak for themselves (they retired my SM number ;-). Filip Pizlo August 30, 2013 10:41 AM On Aug 30, 2013, at 9:28 AM, Brendan Eich > wrote: Hi, Filip Pizlo August 2

Re: Non-extensibility of Typed Arrays

David Herman wrote: > Typed Arrays are a different beast that already exist in the real world. I don't see any need for consistency between Typed Arrays and struct types. Consistency between Typed Arrays and Array is more important. Mostly agreed, except I'd just refine that to say there's

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 9:28 AM, Brendan Eich wrote: > Hi, >> Filip Pizlo >> 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 s

Re: Should the "length" property of bound functions be configurable

Filed bug: https://bugs.ecmascript.org/show_bug.cgi?id=1868 —Claude Le 30 août 2013 à 18:34, Brendan Eich a écrit : > Allen probably could use a bug on file at bugs.ecmascript.org -- anyone? > > /be > >> Claude Pache >> August 30, 2013 5:35 AM >> The `uncurryTh

Re: Should the "length" property of bound functions be configurable

Cool. In that case we have more freedom. In any case, we should give both of these the same attributes. On Fri, Aug 30, 2013 at 10:34 AM, Claude Pache wrote: > > Le 30 août 2013 à 18:54, "Mark S. Miller" a écrit : > > > It seems we have legacy saying that "name" should be writable. > > > > Real

Re: Should the "length" property of bound functions be configurable

Le 30 août 2013 à 18:54, "Mark S. Miller" a écrit : > It seems we have legacy saying that "name" should be writable. > Really? Just tried in the console of the latest stable versions of Firefox, Safari, Chrome and IE: ``` Object.getOwnPropertyDescriptor(function() {}, 'name') ``` Firefox, S

Re: Parameter to promise constructor

On Fri, Aug 30, 2013 at 7:33 AM, Nathan Wall wrote: > Domenica Denicola wrote: >> Since there's no real advantage to the `PromiseResolver` approach, and there >> are a number of disadvantages, we were hoping to switch to the prevalent >> `(resolve, reject)` signature in the revised DOM promises

Re: Should the "length" property of bound functions be configurable

I think a function's "name" and "length" should have similar attributes. It seems we have legacy saying that "name" should be writable. This may be unfortunate, but consistency between the two is the more important principle. On Fri, Aug 30, 2013 at 9:34 AM, Brendan Eich wrote: > Allen probably

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 10:13 AM, David Herman wrote: > On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock wrote: > >> I think the right-way to think about structs is as an record structure with >> no properties fixed behavior provided by a "wrapper". Very similar to the >> ES primitives except tha

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 9:39 AM, Allen Wirfs-Brock wrote: > I think the right-way to think about structs is as an record structure with > no properties fixed behavior provided by a "wrapper". Very similar to the ES > primitives except that structs can be mutable. The way to associate > propertie

Re: Non-extensibility of Typed Arrays

Dave Herman's "And the other consistency dimension is between array types and struct types. Is anyone arguing that structs should also have expandos?" surprised me, and convinced me of the opposite conclusion. Do you think instances of struct types should be extensible? On Fri, Aug 30, 2013 at 8:

Re: Non-extensibility of Typed Arrays

On Aug 30, 2013, at 8:53 AM, Mark S. Miller wrote: > Dave Herman's "And the other consistency dimension is between array types and > struct types. Is anyone arguing that structs should also have expandos?" > surprised me, and convinced me of the opposite conclusion. Do you think > instances of

Re: Should the "length" property of bound functions be configurable

Allen probably could use a bug on file at bugs.ecmascript.org -- anyone? /be Claude Pache August 30, 2013 5:35 AM The `uncurryThis` metafunction, given as example in [1], needs to correct the length of a function produced by `bind`. Simplified version: ``` unc

Re: Non-extensibility of Typed Arrays

This thread has convinced my that Typed Arrays should be born extensible. Actually, my subclass example in the thread started me down that path. In many cases where you might subclass an array you will want to add per instance state. You can expose a getter/setter on the prototype but the sta

Re: Parameter to promise constructor

Passing around just the resolve function is another way to encode that same functionality with no loss of generality, since one can call the resolve with a rejected promise, in order to reject the previously returned promise. The reject function is just a convenience for that. (The resolve functio

RE: Parameter to promise constructor

Note that this turns the common use case on its head.  The creator of the promise passes the resolver to the outside party and holds onto the promise itself.  That's why it's been helpful two full objects with different roles. Nathan Nathan Wall wrote: > Domenica Denicola wrote: >> Since ther

RE: Parameter to promise constructor

Domenica Denicola wrote: > Since there's no real advantage to the `PromiseResolver` approach, and there > are a number of disadvantages, we were hoping to switch to the prevalent > `(resolve, reject)` signature in the revised DOM promises spec. > > Let us know what you think! One advantage to t

Re: Request license change

Hi, What sort of derivative work do you want to do? David Le 30/08/2013 15:44, Musical Notation a écrit : This document and possible translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be pr

Parameter to promise constructor

Anne, Mark, and I are working through the details on revising DOM promises to match the updated AP2 consensus we've developed over these many es-discuss promise threads. There is one change we were hoping to make from the DOM promises spec that has not been discussed before, so we wanted to run

Request license change

> This document and possible translations of it may be copied and furnished to > others, and derivative works that comment on or otherwise explain it or > assist in its implementation may be prepared, copied, published, and > distributed, in whole or in part, without restriction of any kind, pro

Re: Should the "length" property of bound functions be configurable

The `uncurryThis` metafunction, given as example in [1], needs to correct the length of a function produced by `bind`. Simplified version: ``` uncurryThis = f => Function.protytpe.call.bind(f) // uncurryThis(f).length == 1 instead of f.length + 1 ``` So, yes, `bind` should produce fun

Should the "length" property of bound functions be configurable

The latest spec revision makes the function "length" property configurable (section 8.3.16.6). Function.prototype.bind (15.3.3.5) still produces functions with non-configurable "length", however. I think this may be an oversight, but I'm not sure. ___