Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Wed, Nov 9, 2011 at 12:12 AM, Mark S. Miller wrote: > On Tue, Nov 8, 2011 at 9:03 PM, Rick Waldron wrote: > >> >> Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel) >> > > The latest externally visible Opera is Opera 12 alpha build 1116. It is > indeed very close to ES5

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 9:03 PM, Rick Waldron wrote: > > Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel) > The latest externally visible Opera is Opera 12 alpha build 1116. It is indeed very close to ES5.1 compliant. But it still fails http://hg.ecmascript.org/tests/te

Re: Lecture series on SES and capability-based security by Mark Miller

One more thought: people are already avoiding "use strict"; because it bites back: * concatenation with non-strict code and under-testing, but let's hope we are past this now; * performance dinged a bit by strict mode, or at least non-strict calling strict and vice versa. We should try to avoi

Re: Standard Prelude (was: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance))

Let's answer this once we have the module-ized version of the standard library. Which I've been promising for far too long (mea culpa). Will get started on this tonight. Dave On Nov 8, 2011, at 9:04 PM, Brendan Eich wrote: > On Nov 8, 2011, at 8:39 PM, David Herman wrote: > >> Instead of taki

Standard Prelude (was: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance))

On Nov 8, 2011, at 8:39 PM, David Herman wrote: > Instead of taking a hard-to-use-right form like for-in and partly taming it, > I'd rather suggest people simply move to for-of, and have the default keys > iterator Do The Right Thing and only iterate over own, enumerable property > names (thank

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 9:08 PM, Jake Verbaten wrote: > In the real world IE<9 still accounts for almost 50% of browsers. Then > there's another 6% for FF3.6 and another 3% for opera. Latest Opera builds are 100% ES5.1 compliant. (according to opera dev-rel) > > As much as I like promoting that y

Re: Lecture series on SES and capability-based security by Mark Miller

http://www.google.com/support/forum/p/Google+Docs/thread?tid=0cd4a00bd4aef9e4 But yes. Because the difference would be silent, I'm skeptical too. On Tue, Nov 8, 2011 at 8:23 PM, David Herman wrote: > And another silent semantic change? I wouldn't be so quick to do that. And > that's not the dire

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

> Still there, but write it out fully, to compare to the cited text: > > import keys from "@iter"; > for (i of keys(o)) { > body > } > > Unless we default-import a standard prelude, I think we should. > this is a bit much compared to add own as a modifier after for in for/in (not > f

Re: Lecture series on SES and capability-based security by Mark Miller

And another silent semantic change? I wouldn't be so quick to do that. And that's not the direction we were going for __proto__ in the last f2f. I *wish* __proto__ were just treated as another normal property. And I'd like for us to work towards a future where that's the case. I'm just skeptical

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

In the real world IE<9 still accounts for almost 50% of browsers. Then there's another 6% for FF3.6 and another 3% for opera. As much as I like promoting that you should ignore legacy browsers, for most people "50% market share" is a good enough reason to support them. On Wed, Nov 9, 2011 at 2:03

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 08/11/11 23:59, Jake Verbaten wrote: However on average a lot more people will use for ... in with hasOwnProperty because ES5 environments are rare and a lot of people avoid the ES5-shim Do you mean `rare' as in they have to work with the lowest common denominator (IE)? Because ES5-not-so

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 11:36 PM, Brendan Eich wrote: > > Ignoring performance, a lot of stylish JS hackers use > Object.keys(o).forEach. How many run into the wrong |this| > (arguments/break/continue/return)? Not clear. Something to study. > > /be I personally use `Object.keys()` on all my obje

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 08/11/11 21:36, Brendan Eich wrote: Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach. How many run into the wrong |this| (arguments/break/continue/return)? Not clear. Something to study. Well, I use Object.keys, etc, a lot thorough my code. I can't remember a c

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 6:36 PM, Brendan Eich wrote: > Ignoring performance, a lot of stylish JS hackers use Object.keys(o).forEach. > How many run into the wrong |this| (arguments/break/continue/return)? Not > clear. Something to study. I was curious so I did some grok-ing across my code sample

Re: Lecture series on SES and capability-based security by Mark Miller

On Tue, Nov 8, 2011 at 3:46 PM, Mark S. Miller wrote: > > > On Tue, Nov 8, 2011 at 3:33 PM, David Herman wrote: > >> Perhaps __proto__ should not be writeable in "use strict"? >>> >> >> That's a great idea! This never occurred to me, and I have not heard >> anyone suggest this. Thanks! >> >> >>

Re: Lecture series on SES and capability-based security by Mark Miller

On Tue, Nov 8, 2011 at 3:33 PM, David Herman wrote: > Perhaps __proto__ should not be writeable in "use strict"? >> > > That's a great idea! This never occurred to me, and I have not heard > anyone suggest this. Thanks! > > > Doesn't work. > > obj[(function(__){return __ + "proto" + __})("__"

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 2:26 PM, John J Barton wrote: > On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison wrote: >> Yes, I think JS needs something like this. This is new to no one here, but >> my main concern with using hasOwnProperty is the loss of performance, so I >> think it would be worth explorin

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 2:26 PM, John J Barton wrote: > On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison wrote: >> Yes, I think JS needs something like this. This is new to no one here, but >> my main concern with using hasOwnProperty is the loss of performance, so I >> think it would be worth explorin

Re: Lecture series on SES and capability-based security by Mark Miller

> Perhaps __proto__ should not be writeable in "use strict"? > > That's a great idea! This never occurred to me, and I have not heard anyone > suggest this. Thanks! Doesn't work. obj[(function(__){return __ + "proto" + __})("__")] Dave ___ es-di

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

>> I see two domains for the concept of “own” properties: >> 1. Meta-programming. >> 2. Using objects as dictionaries. > > Thanks, good to focus on use-cases. Both would like shorthand and freedom > from Object.prototype.hasOwnProperty tamper-proofing. > >> Isn’t #2 the majority (at least as far

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On Tue, Nov 8, 2011 at 12:50 PM, Andreas Rossberg wrote: > On 8 November 2011 20:46, Mark S. Miller wrote: > > Nevertheless, I see your point. Many defensive ES5 abstractions will be > less > > defensive than this. If I understand you correctly, your point is > > specifically about the [[Call]] a

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 2:16 PM, David Bruant wrote: > Le 08/11/2011 21:49, Brendan Eich a écrit : >> >> The recommended practice when writing for-in loops in JS today is to write: >> >> for (i in o) { >> if (o.hasOwnProperty(i)) { >> body >> } >> } > As said in the thread your fork

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 2:03 PM, Quildreen Motta wrote: > On 08/11/11 18:49, Brendan Eich wrote: >> >> The recommended practice when writing for-in loops in JS today is to write: >> >> for (i in o) { >> if (o.hasOwnProperty(i)) { >> body >> } >> } >> >> Although many JS developers

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 08/11/11 20:22, Axel Rauschmayer wrote: I see two domains for the concept of “own” properties: 1. Meta-programming. Could you expand on the use of `own' properties for meta-programming? I'm afraid I can't really envision it =/ Whenever you copy properties from one object to another one, you

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 1:48 PM, Claus Reinke wrote: >> for own (i in o) { >> body >> } > > What happened to @iter.keys and 'for (key of keys) {}'? Still there, but write it out fully, to compare to the cited text: import keys from "@iter"; for (i of keys(o)) { body } Unless we default-

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 1:19 PM, Jeremy Ashkenas wrote: > On Tue, Nov 8, 2011 at 3:49 PM, Brendan Eich wrote: > > for own (i in o) { > body > } > > This is a small thing but it might pay off in the long run. > > This is a very useful feature ... but for better or for worse, also shows off

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Nov 8, 2011, at 1:19 PM, Axel Rauschmayer wrote: > I see two domains for the concept of “own” properties: > 1. Meta-programming. > 2. Using objects as dictionaries. Thanks, good to focus on use-cases. Both would like shorthand and freedom from Object.prototype.hasOwnProperty tamper-proofing.

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 1:45 PM, Timmy Willison wrote: > Yes, I think JS needs something like this.  This is new to no one here, but > my main concern with using hasOwnProperty is the loss of performance, so I > think it would be worth exploring more than just syntactic sugar.  But I > don't know h

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

>> I see two domains for the concept of “own” properties: >> 1. Meta-programming. > Could you expand on the use of `own' properties for meta-programming? I'm > afraid I can't really envision it =/ Whenever you copy properties from one object to another one, you are usually doing meta-programming

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

Le 08/11/2011 21:49, Brendan Eich a écrit : The recommended practice when writing for-in loops in JS today is to write: for (i in o) { if (o.hasOwnProperty(i)) { /body/ } } As said in the thread your forked from, this practice is often recommended to not enumerate Object.prototype

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 08/11/11 19:19, Axel Rauschmayer wrote: I see two domains for the concept of “own” properties: 1. Meta-programming. Could you expand on the use of `own' properties for meta-programming? I'm afraid I can't really envision it =/ 2. Using objects as dictionaries. Isn’t #2 the majority (at le

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 08/11/11 18:49, Brendan Eich wrote: The recommended practice when writing for-in loops in JS today is to write: for (i in o) { if (o.hasOwnProperty(i)) { /body/ } } Although many JS developers do not follow the recommendation (out of ignorance or intentionally, doesn't matter).

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

2011/11/8 Andreas Rossberg > On 8 November 2011 20:46, Mark S. Miller wrote: > > Nevertheless, I see your point. Many defensive ES5 abstractions will be > less > > defensive than this. If I understand you correctly, your point is > > specifically about the [[Call]] and [[Construct]] traps. > >

Re: for..in, hasOwnProperty(), and inheritance

Le 08/11/2011 08:59, Felipe Gasper a écrit : Hi everyone, There is a widespread practice of doing this: - for (key in obj) { if (obj.hasOwnProperty(key)) { … } } - The oft-stated purpose for this pattern is to weed out code that comes from Object.prototype. The result,

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

for own (i in o) { body } What happened to @iter.keys and 'for (key of keys) {}'? http://wiki.ecmascript.org/doku.php?id=harmony:iterators Claus http://clausreinke.github.com/ http://clausreinke.github.com/js-tools/ ___ es-discuss mailing list

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

Yes, I think JS needs something like this. This is new to no one here, but my main concern with using hasOwnProperty is the loss of performance, so I think it would be worth exploring more than just syntactic sugar. But I don't know how realistic it is to hope for that. http://jsperf.com/hasownp

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 3:49 PM, Brendan Eich wrote: > > for own (i in o) { > *body* > } > > This is a small thing but it might pay off in the long run. > This is a very useful feature ... but for better or for worse, also shows off how much paren-free would help things. "for own key in o

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

I see two domains for the concept of “own” properties: 1. Meta-programming. 2. Using objects as dictionaries. Isn’t #2 the majority (at least as far as non-library-programmers are concerned)? Will the concept become less relevant once we have David Herman’s dicts? I also like the Python-style i

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On Tue, Nov 8, 2011 at 12:49 PM, Brendan Eich wrote: > The recommended practice when writing for-in loops in JS today is to write: >   for (i in o) { >     if (o.hasOwnProperty(i)) { >       body >     } >   } > Although many JS developers do not follow the recommendation (out of > ignorance or in

Re: for..in, hasOwnProperty(), and inheritance

On 11/8/11 2:19 PM, Brendan Eich wrote: On Nov 8, 2011, at 12:12 PM, Luke Smith wrote: Sure. People make "classes" by defining function C(){} and decorating C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will see all the methods, unlike the case with built-in constr

Re: for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

On 11/8/11 2:49 PM, Brendan Eich wrote: Should ES.next provide sugar for the recommended pattern? To make it compose with declarations and destructuring in the for head, it should use a contextual keyword immediately after 'for': for own (i in o) { /body/ } This is a small thing but it might p

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 20:46, Mark S. Miller wrote: > In general, for an object to be defensive, much of the surface reachable > from it by transitive prototype and reflective property traversal should > usually be frozen, and at least non-extensible. This is possible to express > in ES5 >

for own(...) loop (spin-off from Re: for..in, hasOwnProperty(), and inheritance)

The recommended practice when writing for-in loops in JS today is to write: for (i in o) { if (o.hasOwnProperty(i)) { body } } Although many JS developers do not follow the recommendation (out of ignorance or intentionally, doesn't matter). Should ES.next provide sugar for the

Re: for..in, hasOwnProperty(), and inheritance

On 11/8/11 2:19 PM, Jake Verbaten wrote: Flexibility of shared state? Are you really corrupting the state of defaults at runtime? Do you really want changes to your default options to propogate to all objects extending the defaults? It’s the same thing as redefining a method inherited from a p

Re: for..in, hasOwnProperty(), and inheritance

On Nov 8, 2011, at 12:12 PM, Luke Smith wrote: >> Sure. People make "classes" by defining function C(){} and decorating >> C.prototype.method1 = function(...){...}, etc. A for-in loop on (new C) will >> see all the methods, unlike the case with built-in constructors. That is an >> unwanted abst

Re: for..in, hasOwnProperty(), and inheritance

Flexibility of shared state? Are you really corrupting the state of defaults at runtime? Do you really want changes to your default options to propogate to all objects extending the defaults? This seems like a right pain in the ass to debug/maintain? On Nov 8, 2011 8:12 PM, "Luke Smith" wrote:

Re: for..in, hasOwnProperty(), and inheritance

Brendan EichNovember 8, 2011 11:59 AM On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote: Actually, have you ever seen a use case of wanting to prevent iteration through inherited properties *other* than Object.prototype? (Besides using for..in on Array objects.) Sure. People make "cl

Re: for..in, hasOwnProperty(), and inheritance

On Nov 8, 2011, at 11:48 AM, Felipe Gasper wrote: > Actually, have you ever seen a use case of wanting to prevent iteration > through inherited properties *other* than Object.prototype? (Besides using > for..in on Array objects.) Sure. People make "classes" by defining function C(){} and decora

Re: for..in, hasOwnProperty(), and inheritance

On 11/8/11 1:17 PM, Axel Rauschmayer wrote: What’s the use case? In YUI, it’s impossible to use this otherwise-useful pattern: - var base_config = { width: "600px" }; … var my_config = Object.create(base_config); my_config.visible = false; var widget = new Y.Widget(my_config); -

Re: for..in, hasOwnProperty(), and inheritance

You shouldnt store properties on the prototype chain like that. Your abusing Object.create as a shallow copy. Use a real shallow copy method. On Nov 8, 2011 7:07 PM, "Felipe Gasper" wrote: On 11/8/11 12:37 PM, Axel Rauschmayer wrote: > > What’s the use case? I thought I gave a pretty reasonable

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On Tue, Nov 8, 2011 at 11:29 AM, Andreas Rossberg wrote: > On 8 November 2011 19:13, Mark S. Miller wrote: > > The reason Proxy.attach may not be fatal is that it only allows > attachment > > to extensible objects. Our hypothesis is that any ES5 object that is > > interested in defending itself h

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 20:29, Andreas Rossberg wrote: > On 8 November 2011 18:47, David Bruant wrote: >> "Given that direct proxies are not in a position to violate any of the >> *non-configurability or non-extensibility constraints* of their wrapped >> target, it should be safe to replace an existin

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 8 November 2011 18:47, David Bruant wrote: > "Given that direct proxies are not in a position to violate any of the > *non-configurability or non-extensibility constraints* of their wrapped > target, it should be safe to replace an existing normal object by a > direct proxy wrapping that object

Re: for..in, hasOwnProperty(), and inheritance

>> What’s the use case? > > I thought I gave a pretty reasonable one before, but just in case: Thanks! Shorter is better... ;-) > In YUI, it’s impossible to use this otherwise-useful pattern: > - > var base_config = { width: "600px" }; > … > var my_config = Object.create(base_config); >

Re: for..in, hasOwnProperty(), and inheritance

On 11/8/11 12:37 PM, Axel Rauschmayer wrote: What’s the use case? I thought I gave a pretty reasonable one before, but just in case: In YUI, it’s impossible to use this otherwise-useful pattern: - var base_config = { width: "600px" }; … var my_config = Object.create(base_config); my_co

Re: [Proxies] Refactoring prototype climbing in the spec

On Nov 8, 2011, at 7:33 AM, Andreas Rossberg wrote: > On 7 November 2011 16:54, Tom Van Cutsem wrote: >> I wrote up an initial (but fairly complete) draft of a proposed refactoring >> of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way >> in which these algorithms climb

Re: for..in, hasOwnProperty(), and inheritance

What’s the use case? Don’t forget that whenever you set a property, you only ever modify the first object in the prototype chain. The “own property” debate mainly exists, because objects are (ab)used as dictionaries. Then you don’t want inherited entries such as "toString". On Nov 8, 2011, at

Re: for..in, hasOwnProperty(), and inheritance

Whats wrong with enumeration over own properties? Object.keys() gets all enumerable own properties in a for .. in loop. for .. in gets all enumerable properties in prototype chains. I personally think it's bad practice to have code that enumerates over properties in the prototype chain. I can't

for..in, hasOwnProperty(), and inheritance

Hi everyone, There is a widespread practice of doing this: - for (key in obj) { if (obj.hasOwnProperty(key)) { … } } - The oft-stated purpose for this pattern is to weed out code that comes from Object.prototype. The result, though, is that we prevent iteration thr

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On Tue, Nov 8, 2011 at 5:26 AM, Andreas Rossberg wrote: > On 3 November 2011 23:55, Mark S. Miller wrote: > >> If I understood Mark correctly, the features needed for SES are > >> already part of ES.5 and are shipping in browsers > >> > >> (and hence don't bear upon future features). Did I misun

Re: [Proxies] Refactoring prototype climbing in the spec

This is all going in a good direction. I only have a few minor comments: I don't think that [[GetP]] and [[PutP]] need to be "internal methods" In spec'ing this I think I would make them be "abstract operations". Internal methods are extensions points that can be over-ridden on a per object basi

Re: Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

Le 08/11/2011 14:26, Andreas Rossberg a écrit : > On 3 November 2011 23:55, Mark S. Miller wrote: >>> If I understood Mark correctly, the features needed for SES are >>> already part of ES.5 and are shipping in browsers >>> >>> (and hence don't bear upon future features). Did I misunderstand? >>

Re: [Proxies] Refactoring prototype climbing in the spec

Le 08/11/2011 11:54, Tom Van Cutsem a écrit : > > > About [[SetP]]: > * It seems to me that we've traded a duplicated [[GetProperty]] > call for > a duplicated [[GetOwnProperty]] (Step 1 and 5.a) call on the receiver. > This could be avoided by storing the property descriptor

Re: An array destructing specification choice

On Nov 8, 2011, at 4:01 AM, Andreas Rossberg wrote: > I was assuming that we want > > let [x, y,z, ...r] = [1, 2, 3, 4, 5] > > to bind r to [4, 5]. For that to hold, you have to shift down the > numeric indices in _r by 3, which is what the slice call was intended > to do. Gotcha, my mistake

Re: [Proxies] Refactoring prototype climbing in the spec

On 7 November 2011 16:54, Tom Van Cutsem wrote: > I wrote up an initial (but fairly complete) draft of a proposed refactoring > of the ES5 [[Get]], [[Put]] and [[HasProperty]] algorithms to change the way > in which these algorithms climb the prototype > chain: 

Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

On 3 November 2011 23:55, Mark S. Miller wrote: >> If I understood Mark correctly, the features needed for SES are >> already part of ES.5 and are shipping in browsers >> >> (and hence don't bear upon future features).  Did I misunderstand? > > These do bear on future features in three ways: > > 1

Re: An array destructing specification choice

On 7 November 2011 22:46, Brendan Eich wrote: > On Nov 7, 2011, at 3:04 AM, Andreas Rossberg wrote: >> One possible semantics could be treating >> >>  let [x, y, z, ...r] = e >> >> as equivalent to >> >>  let {0: x, 1: y, 2: z, ..._r} = e >>  let r = [].slice.call(_r, 3) >> >> where I assume the "

Re: [Proxies] Refactoring prototype climbing in the spec

> > I am a big fan of this refactoring. > I like the idea that the algorithm transfers full control to the proxy. > Also, accepting this strawman would solve my inherited event properties > problem because I would have access to the receiver from the get trap > and would be able to do the binding I

Re: An array destructing specification choice

On 7 November 2011 18:42, Allen Wirfs-Brock wrote: > > or >    let [first,second] = "abc"; Yes, that's a more convincing example -- although we should probably be aware that users will then also do let [x, y, ...s] = somestring and expect it to slice a string efficiently. /Andreas __

Re: Are some es-discuss submissions automatically blocked?

We use Google Postini in concert with Mailman. Postini needs to be told sometimes. If you don't see mail get through, mail es-discuss-ow...@mozilla.org about it. /be While that has helped usually, in this particular case my email to es-discuss-owner (19.10.2011) also disappeared without reply