Re: lexical for-in/for-of loose end

On Mon, Jan 30, 2012 at 18:38, Brendan Eich wrote: > I think we should break unconditionally and forbid =i in for(var x=i in o) > too, but that is a separate issue. This botch in grammar factoring is a > (bad) sunk cost that has zero bearing on the fresh let binding per iteration > idea. It's terr

Re: lexical for-in/for-of loose end

No! We have a standing agreement to get rid of the awful, lazy-grammar-reuse error in ES1 that allows an initializer in for(var x=i in o). We do not want this at all for 'let' in either for-in or for-of. I think we should break unconditionally and forbid =i in for(var x=i in o) too, but that i

lexical for-in/for-of loose end

Here is valid ES6 for-in statement: for (let p=alert("initializing p"+p) in [0,1]) alert(p); Each iteration gets a fresh p, but does it produce three alerts saying: Initializing p 0 1 or four alerts saying Initializing p 0 Initializing p 1 I would expect the first alternative. Ho

Re: Any plan for a Zlib API ?

any sort of real time sharing editing/documentation document even to go (3G) plus I want to shrink those bloody 50Mb of Web SQL or 5Mb of localStorage limit ... 5Mb ain't nothing for data, we all know that, neither are 50, while native apps, talking about mobile, get as much as they want with a si

Re: Any plan for a Zlib API ?

Why wouldn't you just fix this at the HTTP level with Content-Transfer-Encoding negotiation of some sort? Out of curiosity, what are you sending to the server that that requires additional compression? Remember that zlib is not useful on PNG, JPEG, etc content. Wes -- Wesley W. Garland Directo

Any plan for a Zlib API ?

it's quite common to send a consistent amount of data in certain applications and the FORM does not scale here while an Ajax POST or an upload via binary gripped data would be handy. It would also be handy to store a bit more data in localStorage, Web SQL ( for those that won't drop it ) and/or In

Re: Module linking (Was: The global object should not be the "global scope instance object")

On Jan 30, 2012, at 12:09 PM, Andreas Rossberg wrote: > (Just a quick reply, because I'm in a bit of a hurry.) > > On 30 January 2012 19:17, Allen Wirfs-Brock wrote: ... > > The analysis is not as straightforward as it might seem. In particular, this: > >> The exported name list o

Re: Let's kill terms "native" and "host"

Andreas Rossberg wrote: On 30 January 2012 20:17, Oliver Hunt wrote: > From the PoV of JSC I suspect our biggest problem will actually be our API, which essentially allows developers to override an arbitrary collection of [[SomeInternalMethod]] methods, potentially inconsistently (a sad fac

Re: Module linking (Was: The global object should not be the "global scope instance object")

(Just a quick reply, because I'm in a bit of a hurry.) On 30 January 2012 19:17, Allen Wirfs-Brock wrote: >>> >>> module a { >>>    import {x:y} from b; >> >> I think you wanted to say {y:x} here. > > no, I think  {x:y}  means creating a binding for x that is linked to b.y It's supposed to be r

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 11:41 AM, Allen Wirfs-Brock wrote: >> From the PoV of JSC I suspect our biggest problem will actually be our API, >> which essentially allows developers to override an arbitrary collection of >> [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of >> our

Re: Module linking (Was: The global object should not be the "global scope instance object")

On Jan 30, 2012, at 11:10 AM, Brendan Eich wrote: >> Allen Wirfs-Brock >> January 30, 2012 10:17 AM >> On Jan 30, 2012, at 5:00 AM, Andreas Rossberg wrote: >> >>> On 28 January 2012 02:08, Allen Wirfs-Brock wrote: I played around a bit to see if I could come

Re: Let's kill terms "native" and "host"

On 30 January 2012 20:17, Oliver Hunt wrote: > From the PoV of JSC I suspect our biggest problem will actually be our API, > which essentially allows developers to override an arbitrary collection of > [[SomeInternalMethod]] methods, potentially inconsistently (a sad fact of our > api is that y

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 11:17 AM, Oliver Hunt wrote: > > On Jan 30, 2012, at 11:00 AM, Brendan Eich wrote: > >> Allen Wirfs-Brock wrote: Can we get rid of the concept of "Foreign Object" entirely, and just treat all the objects we have in mind (e.g. DOM nodes) as "Built in proxy ob

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 11:00 AM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >>> Can we get rid of the concept of "Foreign Object" entirely, and just treat >>> all the objects we have in mind (e.g. DOM nodes) as "Built in proxy >>> objects"? >> >> Possibly, but my gut says that is a step too f

Re: Module linking (Was: The global object should not be the "global scope instance object")

Allen Wirfs-Brock January 30, 2012 10:17 AM On Jan 30, 2012, at 5:00 AM, Andreas Rossberg wrote: On 28 January 2012 02:08, Allen Wirfs-Brock wrote: I played around a bit to see if I could come up with a troublesome example of the sort you may be thinking about.

Re: The global object should not be the "global scope instance object"

Andreas Rossberg wrote: What are you proposing for module bindings then? They would have to be visible later on for the "use modules" excuse to work. Do they clash/shadow/overwrite? You're right, it doesn't pay to try to fence off 'let' and 'const'.Indeed your next reply (to Allen) convinces m

Re: Let's kill terms "native" and "host"

Allen Wirfs-Brock wrote: Can we get rid of the concept of "Foreign Object" entirely, and just treat all the objects we have in mind (e.g. DOM nodes) as "Built in proxy objects"? Possibly, but my gut says that is a step too far for this iteration of the spec. If we could, then we could also ge

Re: Let's kill terms "native" and "host"

Mark S. Miller January 30, 2012 10:19 AM On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock mailto:al...@wirfs-brock.com>> wrote: Here is a first cut at some improved terminology: ECMAScript Object - an object whose primitive semantics are specified by t

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 10:19 AM, Mark S. Miller wrote: > On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock > wrote: > Here is a first cut at some improved terminology: > > ECMAScript Object - an object whose primitive semantics are specified by the > ECMAScript specification > Foreign Object -

Re: The global object should not be the "global scope instance object"

On Jan 30, 2012, at 10:11 AM, Andreas Rossberg wrote: > On 30 January 2012 18:16, Allen Wirfs-Brock wrote: >> Assuming this is a single Program or StatementList, the above is current >> defined as being a static error. The above would require changing decisions >> that have already been made so

Re: Let's kill terms "native" and "host"

On Sun, Jan 29, 2012 at 1:25 PM, Allen Wirfs-Brock wrote: > Here is a first cut at some improved terminology: > > ECMAScript Object - an object whose primitive semantics are specified by > the ECMAScript specification > Foreign Object - an object whose primitive semantics differ from those > speci

Re: Module linking (Was: The global object should not be the "global scope instance object")

On Jan 30, 2012, at 5:00 AM, Andreas Rossberg wrote: > On 28 January 2012 02:08, Allen Wirfs-Brock wrote: >> I played around a bit to see if I could come up with a troublesome example >> of the sort you may be thinking about. What I came up with is the follow: >> >> >> module a { >>import

Re: The global object should not be the "global scope instance object"

On 30 January 2012 18:16, Allen Wirfs-Brock wrote: > Assuming this is a single Program or StatementList, the above is current > defined as being a static error.  The above would require changing decisions > that have already been made so I don't see why we should be considering such > cases unless

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 9:05 AM, Wes Garland wrote: > On 30 January 2012 11:56, Allen Wirfs-Brock wrote: > this was part of what I was trying to get at in using the phrase "application > level semantics". The distinction really isn't very different from object > created via object literals (or an

Re: Let's kill terms "native" and "host"

On 30 January 2012 11:56, Allen Wirfs-Brock wrote: > this was part of what I was trying to get at in using the phrase > "application level semantics". The distinction really isn't very different > from object created via object literals (or any other standard mechanism). > They clearly are ECMA

Re: The global object should not be the "global scope instance object"

On Jan 30, 2012, at 4:15 AM, Andreas Rossberg wrote: > On 28 January 2012 02:08, Allen Wirfs-Brock wrote: >> On Jan 27, 2012, at 12:07 AM, Andreas Rossberg wrote: > ... > I was referring to something else in the above quote. For ES, the > conflict between recursive scoping and shadowing is perha

Re: Let's kill terms "native" and "host"

On Jan 30, 2012, at 2:10 AM, Andreas Rossberg wrote: > On 29 January 2012 20:25, Allen Wirfs-Brock wrote: >> Here is a first cut at some improved terminology: >> >> ECMAScript Object - an object whose primitive semantics are specified by the >> ECMAScript specification >> Foreign Object - an ob

Re: __proto__ security

On Jan 30, 2012, at 7:08 AM, Mark S. Miller wrote: > On Sun, Jan 29, 2012 at 6:25 PM, Allen Wirfs-Brock > wrote: > [...] > I would specify it as a modification to the normal [[Get]] and [[Put]] > behavior that special cases on the property key value "__proto__". That > special case (of [[Put

Re: __proto__ security

-1 to adding yet another attribute to the object model (expanding it 16%) unless the payoff is huge. Regarding < http://wiki.ecmascript.org/doku.php?id=strawman:fixing_override_mistake>, we should simply make a decision one way or another rather than add yet another knob. On Mon, Jan 30, 2012 at 3

Re: __proto__ security

On Sun, Jan 29, 2012 at 6:25 PM, Allen Wirfs-Brock wrote: [...] > I would specify it as a modification to the normal [[Get]] and [[Put]] > behavior that special cases on the property key value "__proto__". That > special case (of [[Put]]) would not call [[DefineOwnPropertry]]. It would > include

Re: Let's kill terms "native" and "host"

> > On 29 January 2012 20:25, Allen Wirfs-Brock wrote: > > Here is a first cut at some improved terminology: > > > > ECMAScript Object - an object whose primitive semantics are specified by > the > > ECMAScript specification > > Foreign Object - an object whose primitive semantics differ from thos

Module linking (Was: The global object should not be the "global scope instance object")

On 28 January 2012 02:08, Allen Wirfs-Brock wrote: > I played around a bit to see if I could come up with a troublesome example > of the sort you may be thinking about.  What I came up with is the follow: > > > module a { >    import {x:y} from b; I think you wanted to say {y:x} here. >    modu

Re: The global object should not be the "global scope instance object"

On 28 January 2012 02:08, Allen Wirfs-Brock wrote: > On Jan 27, 2012, at 12:07 AM, Andreas Rossberg wrote: >> Yes, every binding sees every other binding in the same scope >> (including itself). It is not clear to me how that can be combined >> with intra-scope shadowing. Which instance of a name

Re: The global object should not be the "global scope instance object"

On 27 January 2012 23:49, Brendan Eich wrote: > OTOH, people may think "oh, finally! const!" and use const declarations in > an early/common script, wanting to see them later on. I still think we could > say "sorry, script-local" and then "use a module". Yes, I cannot imagine that this would not

Re: Let's kill terms "native" and "host"

On 29 January 2012 20:25, Allen Wirfs-Brock wrote: > Here is a first cut at some improved terminology: > > ECMAScript Object - an object whose primitive semantics are specified by the > ECMAScript specification > Foreign Object - an object whose primitive semantics differ from those > specified by

Re: A fun little spec deviation in the major JS engines

On 29 January 2012 04:13, Jeff Walden wrote: > At least, if you consider |with| and |eval| fun (and who doesn't?): > >  js> var x = "outer"; function f() { with({ x: 17 }) eval("var x"); return > x; } typeof f() >  "undefined" This is really just an instance of JavaScript's, er, creative rules fo

Re: "Static" inheritance of builtins

"Only" from principal point of view. With new <| operator doing parallel hierarchy between functions (and hoping to get classes do the same, though if I didn't misread the proposal, extends does not do that; not to mention I dislike extends in favour of <| which already does that), the notion o

Re: __proto__ security

Gavin Barraclough wrote: I just don't see why we would want to muddy up some core mechanisms of the object model, making them more difficult for users of the language to understand, for the non-benefit of making __proto__ appear to be something that it isn't. It just seems like a bad idea wrapped