Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Andreas Rossberg
On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win. JavaScript implementations in new or existing eco systems that are not poisoned by web legacy wouldn't be obliged to

Re: Module naming and declarations

2013-05-08 Thread Kevin Smith
Hmm. It's funny, you know, Python programs sometimes say import os and I don't think anyone has ever claimed that the word os there is really just a URL or really just a filename. There are at least two issues underlying this difference: - Other languages are generally free to

Re: Module naming and declarations

2013-05-08 Thread Andreas Rossberg
On 7 May 2013 21:17, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, May 2, 2013 at 10:47 AM, Andreas Rossberg rossb...@google.com wrote: My point on the topic of external naming is that the language (1) should not prescribe any specific naming scheme; (2) should not willfully violate URI

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Allen Wirfs-Brock
On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote: On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win. JavaScript implementations in new or existing eco systems that

Re: Module naming and declarations

2013-05-08 Thread Andreas Rossberg
On 7 May 2013 21:48, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: On Thu, May 2, 2013 at 2:13 PM, Andreas Rossberg rossb...@google.com wrote: On 1 May 2013 01:15, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: There are several reasons why module declarations are important. 1. Right now, every

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Mark Miller
What about your triangle argument? Cheers --MarkM On May 8, 2013, at 7:53 AM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On May 8, 2013, at 12:01 AM, Andreas Rossberg wrote: On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote: What would be gained by moving the property

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Allen Wirfs-Brock
On May 8, 2013, at 8:31 AM, Mark Miller wrote: What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; Let's keep {__proto__: foo} in the slightly disrespectable Annex B box. That keeps it together with O.p.__proto and leaves room

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Andreas Rossberg
On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On May 8, 2013, at 8:31 AM, Mark Miller wrote: What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; Let's keep {__proto__: foo} in the slightly disrespectable

Re: __defineGetter__ returns

2013-05-08 Thread David Bruant
Le 07/05/2013 18:30, Andrea Giammarchi a écrit : You did not answer my question Mark: what is the role of TC39, embrace whatever non-standard crossbrowser thing or filter ideas proposing better alternatives/solutions when necessary in order to have a solid foundation instead of having

Re: __defineGetter__ returns

2013-05-08 Thread Mark Miller
Hi David, I am Mark and speak only for my fraction of TC39 ;). But I am happy with your summary. Thanks. On Wed, May 8, 2013 at 8:47 AM, David Bruant bruan...@gmail.com wrote: Le 07/05/2013 18:30, Andrea Giammarchi a écrit : You did not answer my question Mark: what is the role of TC39,

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread David Bruant
Le 08/05/2013 16:46, Andreas Rossberg a écrit : On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On May 8, 2013, at 8:31 AM, Mark Miller wrote: What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto}; Let's keep

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread David Bruant
Le 08/05/2013 08:01, Andreas Rossberg a écrit : On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win. JavaScript implementations in new or existing eco systems that are not

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Brandon Benvie
On 5/8/2013 9:00 AM, David Bruant wrote: Le 08/05/2013 16:46, Andreas Rossberg a écrit : Isn't Object.create the proper alternative to both {__proto__: } and triangle for objects? What has setPrototypeOf got to do with it? (And why is that on the table all of a sudden?) Object.create only

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Andreas Rossberg
On 8 May 2013 18:06, David Bruant bruan...@gmail.com wrote: Le 08/05/2013 08:01, Andreas Rossberg a écrit : On 8 May 2013 07:10, Mark Miller erig...@gmail.com wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this consistency should win.

Re: Module naming and declarations

2013-05-08 Thread Jason Orendorff
On Tue, May 7, 2013 at 7:21 PM, Domenic Denicola dome...@domenicdenicola.com wrote: I think one point that's being hinted at, but not explicitly called out, is the confusing nature of `import foo` in the proposed scheme. Notably, it shares this confusion with AMD, but not with Node.js. The

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Andrea Giammarchi
I proposed a flag for a reusable setter they told me they have no interest to fragment the language behind these kind of flags ... To all: a new syntax is also more suitable for shims/polyfills, something broken/partial implementation of __proto__.set descriptor cannot replace so, as direction,

RE: Module naming and declarations

2013-05-08 Thread Domenic Denicola
From: Jason Orendorff [jason.orendo...@gmail.com] Here's what you would do under the proposal: ```js // import a module in the same package/project import ./controllers as controllers; // import some other package import backbone as backbone; ``` The surface syntax deliberately follows

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Allen Wirfs-Brock
On May 8, 2013, at 8:46 AM, Andreas Rossberg wrote: On 8 May 2013 17:41, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On May 8, 2013, at 8:31 AM, Mark Miller wrote: What about your triangle argument? There is another way: let obj = Object.setPrototypeOf({x:0, y:0}, pointProto};

Re: Module naming and declarations

2013-05-08 Thread Sam Tobin-Hochstadt
On Wed, May 8, 2013 at 1:03 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: Jason Orendorff [jason.orendo...@gmail.com] Here's what you would do under the proposal: ```js // import a module in the same package/project import ./controllers as controllers; // import some other

RE: Module naming and declarations

2013-05-08 Thread Domenic Denicola
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] How is this in disagreement with what Jason said? His point is that if you're in the module a/b/c, ./controllers refers to a/b/controllers, and backbone refers to backbone. Ah, I see, there are

Re: Module naming and declarations

2013-05-08 Thread Sam Tobin-Hochstadt
On Wed, May 8, 2013 at 2:08 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] How is this in disagreement with what Jason said? His point is that if you're in the module a/b/c,

for-in, shadowing and deleting properties.

2013-05-08 Thread Gareth Smith
Hello, I hope this is the right place to ask this question - please let me know if not! I am trying to understand the specification of for-in, both for ES5 and for ES6, and in particular the interaction between shadowing and adding or deleting properties. Here are the parts of the ES5 spec and

RE: Module naming and declarations

2013-05-08 Thread Domenic Denicola
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] In contrast, usually you want to be using that global version of backbone, not something specific to your library. Of course, you can bundle backbone, and refer to it with ./backbone if that's

Re: Module naming and declarations

2013-05-08 Thread Sam Tobin-Hochstadt
No, we're not trying to prescribe a specific structure. There's a default place to fetch files from, because there has to be _some_ default. However, I expect that most developers will do one of the following (Jason listed these options earlier): 1. Load a script tag with `module backbone { ...

RE: Module naming and declarations

2013-05-08 Thread Domenic Denicola
From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] There's a default place to fetch files from, because there has to be _some_ default. Why? This is the core of my problem with AMD, at least as I have used it in the real world with RequireJS. You

Re: Module naming and declarations

2013-05-08 Thread James Burke
On Wed, May 8, 2013 at 10:44 AM, Sam Tobin-Hochstadt sa...@ccs.neu.edu wrote: How is this in disagreement with what Jason said? His point is that if you're in the module a/b/c, ./controllers refers to a/b/controllers, and backbone refers to backbone. Once you have a module name, there's a

Re: Module naming and declarations

2013-05-08 Thread James Burke
On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola dome...@domenicdenicola.com wrote: From: sam...@gmail.com [sam...@gmail.com] on behalf of Sam Tobin-Hochstadt [sa...@ccs.neu.edu] There's a default place to fetch files from, because there has to be _some_ default. Why? This is the core

RE: Module naming and declarations

2013-05-08 Thread Domenic Denicola
From: James Burke [jrbu...@gmail.com] On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola dome...@domenicdenicola.com wrote: This is the core of my problem with AMD, at least as I have used it in the real world with RequireJS. You have no idea what `require(string)` means---is `string` a

Re: Module naming and declarations

2013-05-08 Thread Sam Tobin-Hochstadt
On Wed, May 8, 2013 at 3:59 PM, Domenic Denicola dome...@domenicdenicola.com wrote: From: James Burke [jrbu...@gmail.com] On Wed, May 8, 2013 at 11:35 AM, Domenic Denicola dome...@domenicdenicola.com wrote: This is the core of my problem with AMD, at least as I have used it in the

Re: Module naming and declarations

2013-05-08 Thread Jason Orendorff
On Wed, May 8, 2013 at 8:22 AM, Kevin Smith zenpars...@gmail.com wrote: - Other languages are generally free to define their own semantics for referencing external things, whereas JavaScript (as embedded in the browser) already has such semantics in-place. Adopting different semantics will

Re: Module naming and declarations

2013-05-08 Thread Kevin Smith
You're saying we have no choice but to make users hard-code locations into every import site, because HTML. I disagree. That is not my position. My position has always been that if you want logical names, then a reasonable way to do that is via a scheme: import $ from package:jquery;

Re: Module naming and declarations

2013-05-08 Thread Jason Orendorff
On Tue, May 7, 2013 at 7:01 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, May 7, 2013 at 4:39 PM, Jason Orendorff jason.orendo...@gmail.com wrote: Set aside absolute-url imports. Suppose we just dropped them. Would you still think that module names are URLs? If so, do you think

Re: for-in, shadowing and deleting properties.

2013-05-08 Thread Andrea Giammarchi
in the Example 1 you simply loop over all keys in the chain, included the x inherited from b. The fact you shadow that is irrelevant, it was there in any case. The fact you get 1 in the log is because you access the shadowed property through a[i] so expected result. You are doing a for/in, not a

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Brendan Eich
Andreas Rossberg wrote: On 8 May 2013 18:06, David Bruantbruan...@gmail.com wrote: Le 08/05/2013 08:01, Andreas Rossberg a écrit : On 8 May 2013 07:10, Mark Millererig...@gmail.com wrote: What would be gained by moving the property alone to Annex B? If nothing, then I think this

Re: Module naming and declarations

2013-05-08 Thread Claus Reinke
That is not my position. My position has always been that if you want logical names, then a reasonable way to do that is via a scheme: import $ from package:jquery; A possible alternative would be to switch the defaults ___ es-discuss mailing

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Brendan Eich
Having Object.setPrototypeOf to match Object.getPrototypeOf is nice, better for proxies (with necessary changes to them), and polyfillable. Take my last note as an attitude adjustment, though. So long as __proto__ endures, its brevity and legacy uses will tend to propagate its use into the

Re: Module naming and declarations

2013-05-08 Thread Claus Reinke
[sorry if you saw an earlier empty message - unknown keycombo!-(] That is not my position. My position has always been that if you want logical names, then a reasonable way to do that is via a scheme: import $ from package:jquery; A possible alternative might be to switch defaults, using

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Dean Landolt
Call me crazy but I can picture a world where you have to explicitly shim in __proto__ (using Object.setPrototypeOf) if you really need it. Not anytime soon, sure, but maybe one day. Maybe... On Wed, May 8, 2013 at 5:05 PM, Brendan Eich bren...@mozilla.com wrote: Having Object.setPrototypeOf

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Jeff Walden
On 05/08/2013 01:58 PM, Brendan Eich wrote: 1. Dumping stuff into Annex B to show disdain. This is pride, bad for the soul. Pride doesn't seem like a reason one way or the other, to me. The reason would be to cordon off functionality whose mis-performance developers will not intuitively

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Brendan Eich
Dean Landolt wrote: Call me crazy but I can picture a world where you have to explicitly shim in __proto__ (using Object.setPrototypeOf) if you really need it. Not anytime soon, sure, but maybe one day. Maybe... Who can say? It's fruitless to speculate idly. Want to bet? But aside from

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Brendan Eich
Jeff Walden wrote: On 05/08/2013 01:58 PM, Brendan Eich wrote: 1. Dumping stuff into Annex B to show disdain. This is pride, bad for the soul. Pride doesn't seem like a reason one way or the other, to me. Good. The reason would be to cordon off functionality whose mis-performance Why

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Jeff Walden
On 05/08/2013 04:10 PM, Brendan Eich wrote: Why would Object.setPrototypeOf have any better perf? It wouldn't. developers will not intuitively understand, so that they're less likely to use it. Some will, even still, perhaps just out of obstinacy (pride, I think you missed that that

Re: B.3.1 The __proto__ pseudo property

2013-05-08 Thread Andrea Giammarchi
it took 8 years to teach JS developers **not** to pollute Object.prototype, I understand your concern and I understand with the possibility to drop enumerability that could (and will) be proposed by someone. At the same time it will be a stubborn move aim to fix some deprecated, old, not