Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Herby Vojčík
Brandon Benvie wrote: A better trap than getOwnPropertyDescriptor would be something like query which is used to look up the attributes of a property and its existence. JS shies away from constants generally, and especially numeric ones, but this is a place I have found really benefits from a

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Brandon Benvie
Woops I forgot ___ which is 0. Non-enumerable, non-configurable, non-writable. Since undefined is what indicates lack of a property, this isn't an issue. As for bounding, it's simple enough to specify the valid range to be 0-12. Or use strings with the names instead of numbers, though that loses

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread David Bruant
Le 12/11/2012 19:17, Allen Wirfs-Brock a écrit : On Nov 12, 2012, at 2:21 AM, Brandon Benvie wrote: Shouldn't it be the reverse, based on the removal of getPropertyDescriptor/Names? The proxy controls what i's [[Prototype]] is which indirectly directs how non-own lookups proceed. The

Re: Promises (David Bruant)

2012-11-13 Thread David Bruant
(sorry for the late answer, I was traveling and at an event since Thursday) Le 12/11/2012 02:46, Leo Meyerovich a écrit : I wasn't aware of this and then read through about a dozen WebAPIs [2] between yesterday and today and... discovered it's the case. In my opinion, one of the most absurd

Re: Promises

2012-11-13 Thread David Bruant
Le 09/11/2012 18:01, John J Barton a écrit : On Fri, Nov 9, 2012 at 4:33 AM, David Bruant bruan...@gmail.com mailto:bruan...@gmail.com wrote: # the Q API ## A Q Deferred is a {promise, reject, resolve} object. Only the deferred holder can resolve the promise (and not the promise

Re: Promises

2012-11-13 Thread David Bruant
Le 10/11/2012 03:14, Brendan Eich a écrit : David Bruant wrote: Personally, to synchronize different async operations, I've never read code more elegant than what Q.all offers. What about task.js's join? https://github.com/mozilla/task.js/blob/master/examples/read.html#L41 I feel it's pretty

Re: Promises

2012-11-13 Thread David Bruant
Le 09/11/2012 17:33, Mark S. Miller a écrit : Hi David, thanks for your thoughtful post. I've always used the two-arg form of .then[1], but your post makes a strong case for more often using separate one-arg .then and .fail calls. I say only more often because the two arg form can easily make

Re: Promises

2012-11-13 Thread David Bruant
Le 11/11/2012 14:44, Kevin Smith a écrit : Is the following a counter-example? On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller erig...@google.com mailto:erig...@google.com wrote: Hi David, thanks for your thoughtful post. I've always used the two-arg form of

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Allen Wirfs-Brock
On Nov 13, 2012, at 1:44 AM, David Bruant wrote: Le 12/11/2012 19:17, Allen Wirfs-Brock a écrit : On Nov 12, 2012, at 2:21 AM, Brandon Benvie wrote: Shouldn't it be the reverse, based on the removal of getPropertyDescriptor/Names? The proxy controls what i's [[Prototype]] is which

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread David Bruant
Le 13/11/2012 19:28, Allen Wirfs-Brock a écrit : On Nov 13, 2012, at 1:44 AM, David Bruant wrote: I'm fine if we're discussing removing some other inconsistencies, but I'd be more interested in seeing a principled way to decide which inconsistency we're getting rid of and which we still

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread David Bruant
Le 13/11/2012 21:25, Tom Van Cutsem a écrit : 2012/11/13 Allen Wirfs-Brock al...@wirfs-brock.com mailto:al...@wirfs-brock.com I think there is agreement that [[HasOwnProperty]] is just an optimization of ToBoolean([[GetOwnPropertuy]]). Its only purpose is to avoid unnecessary

Re: Array.filter: max number of matches?

2012-11-13 Thread Brendan Eich
Andrea Giammarchi wrote: wait, I might have misunderstood your problem ... so you want to stop iterating, right ? When that is the case, you can simply drop the iteration like this: myArray.slice().filter(function (value, index, original) { // do your stuff if (conditionSatisfied) {

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Erik Arvidsson
On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem tomvc...@gmail.com wrote: So, my proposal: let's revert the fundamental traps of Handler to become abstract methods again. This forces subclasses of Handler to provide all fundamentals at once, avoiding the footgun. Maybe we should skip the

Re: Array.filter: max number of matches?

2012-11-13 Thread Andrea Giammarchi
Alex, here is how you should use the Array#some in order to solve your problem: var howManyConditions = 5; yourArray.some(function (value) { if (conditionSatisfied(value)) { --howManyConditions; } return !howManyConditions; }); in this case, as Brendan said, you don't even need a copy.

Re: Array.filter: max number of matches?

2012-11-13 Thread Rick Waldron
On Tue, Nov 13, 2012 at 3:33 PM, Brendan Eich bren...@mozilla.org wrote: Andrea Giammarchi wrote: wait, I might have misunderstood your problem ... so you want to stop iterating, right ? When that is the case, you can simply drop the iteration like this: myArray.slice().filter(**function

Re: Array.filter: max number of matches?

2012-11-13 Thread Andrea Giammarchi
be careful Rick, if no slice() then you might loose data from original Array. that's why I used slice ;-) var a = [1, 2, 3]; a.filter(function(v,k,a){a.length=0}); alert(a); // empty On Tue, Nov 13, 2012 at 3:38 PM, Rick Waldron waldron.r...@gmail.comwrote: On Tue, Nov 13, 2012 at 3:33

Re: Array.filter: max number of matches?

2012-11-13 Thread Rick Waldron
On Tue, Nov 13, 2012 at 7:04 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: be careful Rick, if no slice() then you might loose data from original Array. that's why I used slice ;-) Of course, the non-slice way is like to hell with everything :) var a = [1, 2, 3];

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Allen Wirfs-Brock
On Nov 13, 2012, at 12:25 PM, Tom Van Cutsem wrote: 2012/11/13 Allen Wirfs-Brock al...@wirfs-brock.com I think there is agreement that [[HasOwnProperty]] is just an optimization of ToBoolean([[GetOwnPropertuy]]). Its only purpose is to avoid unnecessary reification of property

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Allen Wirfs-Brock
On Nov 13, 2012, at 12:39 PM, David Bruant wrote: Le 13/11/2012 19:28, Allen Wirfs-Brock a écrit : ... We've explored the security issues or proxies in depth. Now is the time to explore the usability issues. Very good point. Proxies are not intended for novices but there still will

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Allen Wirfs-Brock
On Nov 13, 2012, at 12:52 PM, David Bruant wrote: Le 13/11/2012 21:25, Tom Van Cutsem a écrit : 2012/11/13 Allen Wirfs-Brock al...@wirfs-brock.com I think there is agreement that [[HasOwnProperty]] is just an optimization of ToBoolean([[GetOwnPropertuy]]). Its only purpose is to avoid

Re: Do we really need the [[HasOwnProperty]] internal method and hasOwn trap

2012-11-13 Thread Brendan Eich
Erik Arvidsson wrote: On Tue, Nov 13, 2012 at 3:25 PM, Tom Van Cutsem tomvc...@gmail.com mailto:tomvc...@gmail.com wrote: So, my proposal: let's revert the fundamental traps of Handler to become abstract methods again. This forces subclasses of Handler to provide all fundamentals