Re: Solving the how do I tell whether I have an HTML element? (or image element, or whatever) problem
2013/1/24 Cameron McCormack c...@mcc.id.au
On 18/01/13 9:09 AM, Travis Leithead wrote:
I think this sounds fine. Most web developers don't expect the
current spec'd behavior, even though to me it seems more natural.
IE has the current behavior and I expect we would migrate to the new
behavior at some point once it was defined and agreed upon.
At one point a long time ago, Web IDL did require [[HasInstance]] to be
overridden to return true even for objects from different windows. If
proxies now support trapping that, I'll just add it back.
Just to clarify: we've previously talked about proxies trapping
[[HasInstance]], but instead settled on an approach that does not require
proxies (see below).
I guess this will change to the @hasInstance that Allen mentions, once ES6
stabilises and I actually understand what @hasInstance means. :)
@hasInstance denotes a unique symbol. If a JavaScript object (any object,
doesn't have to be a proxy) defines a property with that symbol as a key,
it will be able to intercept instanceof. My understanding of how this would
work is roughly as follows:
// get the hasInstance symbol from somewhere (e.g. import from a std module)
var hasInstance = ...;
function Foo() {...};
Foo[hasInstance] = function(subject) { return boolean-expression; }
obj instanceof Foo // calls the above function, passing obj as the subject
Cheers,
Tom
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: WeakMap GC performance
After email exchanged with Andreas, it seems that some emails clients (most modern ones?) do not work well when changing the email title; something I hadn't noticed on my own email client. I apologize for the inconvenience to anyone it has bothered and will fork thread less often from now on. David Le 23/01/2013 11:21, Andreas Rossberg a écrit : [Meta] David, I would appreciate if you stopped breaking discussion threads all the time. There are now about half a dozen threads related to WeakMap clear, which clutters the discussion view and makes it hard to properly follow the discussion with delay. Thanks, /Andreas On 23 January 2013 10:49, David Bruant bruan...@gmail.com wrote: [reordering] Allen wrote: We can understand the value of providing a clear method without talking about GC at all. I don't doubt there is a case to clear a data structure, but it can be filled with clearless weakmaps. What I'm trying to find is a differentiating factor. I agree that: * clearable and clear-less weakmaps both have a use. Which is dominant for developers has yet to be determined and only tastes and feelings have been provided so far (including by myself). * clearable weakmaps and clear-less weakmap can be symmetrically and at close to no cost implemented on top of one another. Until evidence (from other languages?) is provided that one case matters more, I personally call this a tie. That's where my reflection is at. I think a major remaining point is performance. If clear-less weakmaps induce an incompressible significant GC cost, then, that is a valid justification to have native .clear. Now, implementors will have to deal with programs where some long-lived weakmaps aren't manually cleared, the interesting question here is: how far can they go to reduce the GC cost (without requiring a major breakthrough in GC research of course ;-) )? If the cost can be reduced to a marginal difference with manual .clear, I call the performance argument a tie too (leaving the debate to a taste/feeling debate) Le 23/01/2013 00:36, Allen Wirfs-Brock a écrit : On Jan 22, 2013, at 2:35 PM, David Bruant wrote: So, to find out if a weakmap is dead, it has to come from another source than the mark-and-sweep algorithm (since it losts its precision)... Given the additional prohibitive cost weakmaps seem to have on the GC, maybe things that would otherwise be considered too costly could make sense to be applied specifically to WeakMaps. For instance, would the cost of reference-counting only weakmaps be worth the benefit from knowing early that the weakmap is dead? (I have no idea how much each costs, so it's hard for me to compare the costs) For WeakMapWithClear, reference counting would declare the weakmap dead as soon as the new weakmap is assigned to the private property so that's good. It wouldn't work if some weakmaps are part of a cycle of course... but maybe that it's such an edge case that it's acceptable to ask users doing that to break their weakmaps cycle manually if they don't want the GC not to be too mad at them. You know, as much as Jason and I enjoy talking about garbage collectors, this probably isn't the place to revisit the last 40 years of a highly developed area of specialized CS technology. Even if there is a .clear method, it doesn't mean people will use it, so the costs weakmaps induce on GC will have to be taken care of even if people don't manually clear the weakmap [forking the thread for this reason]. JS engine implementors will have to solve this problem regardless of the introduction of a .clear method or not. Since JS engines start having generational GC and WeakMaps, I feel here and now might be a very good place and time to revisit these 40 years. Each implementor will have to do this revisit anyway. If anything, this thread may become a good resource for developers to understand why some of their programs using WeakMaps have conjecturally or inherently bad GC characteristics. Of all points in this thread, the one that got stuck in my head is when Jason said: In our current implementation, creating a new WeakMap and dropping the old one is very nearly equivalent in performance to clear(). What this means is that something is lost when moving to a naive generational GC regarding WeakMaps. The loss is the knowledge of when exactly a weakmap is dead. And this loss has a cost related to weakmap GC cost. Although Mark showed a linear algorithm, one can still wonder if in practice this algorithm induce a significant cost (the worst-case complexity doesn't say much about the most-frequent-case cost of an algorithm). What I'm trying to find out is whether there is a small-cost weakmap-specific tracking system that could tell the GC that a weakmap is dead as soon as possible. First and foremost, what did the research find in these 40 years on this specific question? Did it prove that any tracking system doing what I describe would cost so much that it wouldn't save on what it's supposed to?
Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))
Le 24/01/2013 09:52, Tom Van Cutsem a écrit : 2013/1/23 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com Le 23/01/2013 09:38, Tom Van Cutsem a écrit : 3) because of JS's invoke = get + apply semantics, by default a proxy always leaves the |this| value pointing at the proxy. Looking only at 3), sometimes this is what you want, and sometimes it isn't. In which case would it be what you want? See the example by Brendan just upstream in this thread. True, I had read this post too quickly. The example Brandon (and Kevin before him) provided showed something very intrusive about proxies related to your 3). That proxies mediate the access to the public method is one thing, that they pretend to be the object acted on inside the method opens a entire world. Even with fixes suggested by Allen, the hazard can still exist if someone does: Counter.prototype.increment.call(new Proxy(counter, maliciousHandler)) I don't understand why this is a hazard. Even without proxies, |this| is never reliable, unless you use .bind(). I'm not worried about the |this|-reliability for the method, but rather that the target instance can be left in an inconsistent state because of a malicious handler. The important part in the above expression isn't the .call, but that an actual Counter instance is the proxy target. I have no idea how this can be mitigated in general without creating a mechanism that can be abused to unwrap proxies. For classes specifically, maybe an option can make that classes keep track of generated objects and throw if non-instance is passed in a method as |this| (...which is exactly the kind of things DOM Node tree manipulation methods will need) Recall that it was a goal for classes to be a form of sugar over the existing object model. That means the use of |this| within a method specified using class syntax should really be no different from using |this| outside of classes. Let's try to avoid making up special rules for class instances. I agree with you, I suggested to add an option, not to change the default semantics. Because of the too-dynamic |this| and everyone being used to it, protecting yourself from malicious proxies from attacks like the one above (method.call(new Proxy(legitObject, maliciousProxy))) has to be an opt-in. Basically, methods make sure their |this| is an object that came out of the class constructor. It would be nice if this opt-in could be made as simple as an optional keyword in the class syntax. This option would just desugar differently (put all objects created by the constructor in a WeakSet, add a prolog to each method verifying |this| is part of the weakset, continue if yes, throw if not). Going back to the big discussion thread about proxying DOM objects, I maintain that it's a bad idea to try to make existing APIs (that expect objects of a very specific type) work with any random proxy, either by interacting with it or by unwrapping it. The cleaner thing to do would be to replace/wrap the API with one that also recognizes and accepts certain proxies (still not just anyone's proxies). I agree. The selector matching use case convinced me there is no chance to put proxies or weird objects in a DOM tree. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity
Le 22/01/2013 21:09, David Bruant a écrit : Le 22/01/2013 20:05, Tom Van Cutsem a écrit : Symbol-keyed indexing on the A face is distinct from symbol-keyed indexing on the B face. But that's OK: it's the job of the membrane to separate the A and the B face in the first place. I don't think that's ok. A goal of the proxy mediation is to gives A and B the impression they communicate with one another like if there was no mediation (but keeping the right to revoke all communications when necessary). That's why the membrane faithfully forwards primitive values and preserve object identity equalities in other cases than private symbols. If you created A and B and started to make them communicate, it's because you wanted them to collaborate to achieve something for you. If A and B share a private symbol, it's in order to communicate using it. If the membrane changes the symbol, then A and B don't communicate as if there was no mediation anymore. It's even possible that they won't be able to work together if their mutual collaboration relied on communication via the private symbol they expected to share. I've come around to think that auto-unwrapping may be a simpler idea in the end. Maybe in complicated use cases it will require some additional work to not leak private symbols. As explained above, auto-unwrapping would prevent 2 untrusted membraned parties to communicate directly through the private symbols, but the language already provides way enough ways to communicate (public object properties, arguments/return values in function calls). I think it was crucially important that each context is consistent and oblivious to being wrapped and you've explained it could be done efficiently (1-1 mapping of private symbols) so I guess there is no problem on that side. Securing the use private symbols will always require some additional book-keeping and that's unfortunate, but the cost sounds acceptable. Probably a library can be provided to help out proxy authors in the bookkeeping. As you noted, one crucially important point is that no built-in private symbol is introduced in the language. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array method ranges
What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.
As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?
arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);
arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards
Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).
arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)
Of course, it would still skip the holes in sparse arrays.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
Why would you use a square bracket notation rather than a . Property
access notation?
[] is typically only use when the property name is in a variable, which is
not the case when you write your own object.
True - but for symbols, your only option is square brackets:
var sym = new Symbol(), obj = {};
obj[sym] = 42;
So if you go the private symbols route, then you're going to have *lots* of
square brackets.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: Array method ranges
Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't
walk the array backwards properly. Not sure it's worth to have it built-in
though.
Date: Thu, 24 Jan 2013 12:06:23 +0100
Subject: Array method ranges
From: e...@qfox.nl
To: es-discuss@mozilla.org
What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.
As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?
arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);
arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards
Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).
arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)
Of course, it would still skip the holes in sparse arrays.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Private symbols auto-unwrapping proxies (was: Security Demands Simplicity (was: Private Slots))
Just to clarify, the example I gave of WeakMap usage breaking with proxies was just to illustrate how a type of private data currently in use alongside proxies can break the target object purely by accident. While I do think [[CallMethod]] would go a long way to ameliorating the problem, I still believe allowing private symbol keyed properties to have a special immunity to proxies is a useful tool. The advice would be: use private symbols for properties that hold sensitive state to prevent proxies from accidentally breaking instances of your classes. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array method ranges
At this point I think we are better of moving towards iterator
methods. For example if we had an islice like the one in Python's
itertools [*] we can do:
for (let v of islice(arr, start, stop)) {
...
}
this would be equivalent to your proposed
arr.forEach((v) = { ... }, undefined, start, stop)
with the benefit that it composes much better.
[*] http://docs.python.org/2/library/itertools.html#itertools.islice
On Thu, Jan 24, 2013 at 9:45 AM, François REMY
francois.remy@outlook.com wrote:
Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't
walk the array backwards properly. Not sure it's worth to have it built-in
though.
Date: Thu, 24 Jan 2013 12:06:23 +0100
Subject: Array method ranges
From: e...@qfox.nl
To: es-discuss@mozilla.org
What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.
As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?
arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);
arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards
Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).
arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to
length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)
Of course, it would still skip the holes in sparse arrays.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
On Jan 24, 2013, at 5:47, Kevin Smith khs4...@gmail.com wrote:
Why would you use a square bracket notation rather than a . Property access
notation?
[] is typically only use when the property name is in a variable, which is
not the case when you write your own object.
True - but for symbols, your only option is square brackets:
var sym = new Symbol(), obj = {};
obj[sym] = 42;
So if you go the private symbols route, then you're going to have *lots* of
square brackets.
Not in the case where you would use a private property like a regular one if
the language were to offer to tag properties as private, right?
I guess I don't quite understand why it seems contentious to add a private
property to property descriptors which already reserve properties like
value, enumerable or writable.
private is a meta description of a property like value, enumerable or
writable.
That feels a more natural extension than adding class to the language.
Since on the topic of adding more property descriptors, one thing we played
with in Montage is the notions of distinct property descriptor. One amazing
aspect of Ecmascript's prototyping inheritance is it's ability to allow you to
set default values on the objects that one use as prototypes for others. This
is a one time operations, compared to setting initial default state per
instance creation, being in a constructor or init method. It's really efficient
in term of memory footprint as well, and the prototype lookup is so optimized
now that it works well.
There's however a big problem with mutable objects like arrays because if it's
on the prototype, it's shared by all instances. When that's what you want and
sometime you do, great. But if what you had in mind was that each object should
have it's own array for that property, debugging the fist time is fun!
Yes, you can do that in a constructor or init method. But another way is to add
to the property descriptor a property distinct: true . Which means that each
object inheriting from that object would get it's own copy of that object at
creation time.
One problem we found working on that is that unfortunately the language let you
add these properties to the object used as property descriptors but it's lost
after that, meaning that you need to keep a parallel storage to keep track of
it.
All this is more declarative than imperative since you can do it yourself in
constructor/init method, but it adds semantic and cut down code to write, while
being executed in native code by the language itself.
Just wanted to share that.
Thanks!
Benoît
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
Benoit Marchant wrote:
I guess I don't quite understand why it seems contentious to add a
private property to property descriptors which already reserve
properties like value, enumerable or writable.
private is a meta description of a property like value,
enumerable or writable.
That feels a more natural extension than adding class to the language.
As David wrote, this does not work in a dynamic language.
function generic_get(obj, prop) {
return obj[prop];
}
obj = {private foo: 42, get bar() { return this.foo; }}; // or
equivalent class syntax
// elsewhere
var steal = generic_get(obj, 'foo');
How do you enforce that only bar can access foo from obj? A private
attribute on a property with a public string-equated name 'foo' does not
help.
The mistake is treating name privacy as a property attribute. Privacy is
not an attribute of property descriptors, it's a restriction on property
names. It is not a static restriction in any sense, rather a capability.
If you keep the private symbol or weak map confined, privacy is assured.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
Thanks Brendan, that make sense but that's more than what I think I'm looking
for. What I'm looking for is a way to store a value in a object's property that
can only be accessed from a property access stand point by the object itself.
My only goal is to make sure that outside code can't break encapsulation for
code robustness/quality reason.
Isn't it possible internally to allow a property access only by this ?
Benoit
On Jan 24, 2013, at 10:10 AM, Brendan Eich bren...@mozilla.com wrote:
Benoit Marchant wrote:
I guess I don't quite understand why it seems contentious to add a private
property to property descriptors which already reserve properties like
value, enumerable or writable.
private is a meta description of a property like value, enumerable or
writable.
That feels a more natural extension than adding class to the language.
As David wrote, this does not work in a dynamic language.
function generic_get(obj, prop) {
return obj[prop];
}
obj = {private foo: 42, get bar() { return this.foo; }}; // or equivalent
class syntax
// elsewhere
var steal = generic_get(obj, 'foo');
How do you enforce that only bar can access foo from obj? A private attribute
on a property with a public string-equated name 'foo' does not help.
The mistake is treating name privacy as a property attribute. Privacy is not
an attribute of property descriptors, it's a restriction on property names.
It is not a static restriction in any sense, rather a capability. If you keep
the private symbol or weak map confined, privacy is assured.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
Isn't it possible internally to allow a property access only by this ?
Ah-hem:
priv(this).anyPropertyYouWantPlaya;
: )
Using the definition of priv from previous messages is this thread.
{ Kevin }
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Ducks, Rabbits, and Privacy
Benoit Marchant wrote: Isn't it possible internally to allow a property access only by this ? No. For one thing, the design has to include class-private instance variables, not instance-private, so you need other.foo as well as this.foo (consider private x and y for Point2D add method). Also, again, we're not enforcing privacy at the descriptor level with some kind of access control monitor, rather through names (whether symbols or weakmaps) as capabilities. Avoids confused deputy attacks. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array method ranges
Yes, this was the plan. I don't see a strawman, yet. Cc'ing jorendorff.
/be
Erik Arvidsson wrote:
At this point I think we are better of moving towards iterator
methods. For example if we had an islice like the one in Python's
itertools [*] we can do:
for (let v of islice(arr, start, stop)) {
...
}
this would be equivalent to your proposed
arr.forEach((v) = { ... }, undefined, start, stop)
with the benefit that it composes much better.
[*] http://docs.python.org/2/library/itertools.html#itertools.islice
On Thu, Jan 24, 2013 at 9:45 AM, François REMY
francois.remy@outlook.com wrote:
Good idea. However, I don't like the fact arr.forEach(f,null,-1,0) doesn't
walk the array backwards properly. Not sure it's worth to have it built-in though.
Date: Thu, 24 Jan 2013 12:06:23 +0100
Subject: Array method ranges
From: e...@qfox.nl
To: es-discuss@mozilla.org
What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.
As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?
arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);
arr.slice(10,10).forEach...
arr.slice(80,20).reverse().forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards
Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).
arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)
Of course, it would still skip the holes in sparse arrays.
- peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array method ranges
It looks like the beginnings of an outline were added to the standard
modules list living under '@iter' with zip and unzip so far:
http://wiki.ecmascript.org/doku.php?id=harmony:modules_standard. But no
separate strawman yet.
On Thursday, January 24, 2013, Brendan Eich wrote:
Yes, this was the plan. I don't see a strawman, yet. Cc'ing jorendorff.
/be
Erik Arvidsson wrote:
At this point I think we are better of moving towards iterator
methods. For example if we had an islice like the one in Python's
itertools [*] we can do:
for (let v of islice(arr, start, stop)) {
...
}
this would be equivalent to your proposed
arr.forEach((v) = { ... }, undefined, start, stop)
with the benefit that it composes much better.
[*]
http://docs.python.org/2/**library/itertools.html#**itertools.islicehttp://docs.python.org/2/library/itertools.html#itertools.islice
On Thu, Jan 24, 2013 at 9:45 AM, François REMY
francois.remy@outlook.com wrote:
Good idea. However, I don't like the fact arr.forEach(f,null,-1,0)
doesn't walk the array backwards properly. Not sure it's worth to have it
built-in though.
--**--
Date: Thu, 24 Jan 2013 12:06:23 +0100
Subject: Array method ranges
From: e...@qfox.nl
To: es-discuss@mozilla.org
What about adding specific range arguments to the es5 array methods
(forEach, map, etc)? Currently the start (inclusive) and stop
(exclusive) is always 0 ... length, but what if you only want to map
over a sub range of the array? Or maybe I want to traverse the array
in reverse? I'd either have to slice it or .reverse it, neither are
something I would want. So I fall back to `for` or `while` loops.
As for the context parameter, I believe undefined won't change the
context opposed to omitting it, right?
arr.forEach(function(){ ...});
// same as
arr.forEach(function(){ ...}, undefined, 0, arr.length);
arr.slice(10,10).forEach...
arr.slice(80,20).reverse().**forEach...
=
arr.forEach(function(){ ...}, undefined, 10, 20);
arr.forEach(function(){ ...}, undefined, 100, 80); // run from 100 to
80, backwards
Negative numbers could behave the same as in slice (offsets from the
last item, rather than the first).
arr.forEach(function(){ ...}, undefined, -20); // run from length-20 to
length
arr.forEach(function(){ ...}, undefined, -20, -10); // run from
length-20 to length-10 (so, forward)
arr.forEach(function(){ ...}, undefined, -20, -30); // run from
length-20 to length-30 (so, backwards)
Of course, it would still skip the holes in sparse arrays.
- peter
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
__**_
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
