2012/11/12 Allen Wirfs-Brock al...@wirfs-brock.com
It isn't clear to me why the [[HasOwnProperty]] internal method and the
hasOwn Proxy trap need to exist as object behavior extension points.
[...]
let p = new Proxy({}, {
hasOwn(target,key) {return key === 'foo' ? false:
On 12 November 2012 02:17, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
It isn't clear to me why the [[HasOwnProperty]] internal method and the
hasOwn Proxy trap need to exist as object behavior extension points.
Within my current ES6 draft, [[HasOwnProperty]] is only used within the
I *really* don't want to wade deep into these waters, but I'll respond a bit
here to correct errors:
On Nov 11, 2012, at 9:02 PM, Leo Meyerovich lmeye...@gmail.com wrote:
I've been lurking on this thread and am somewhat confused. Is the motivation
for promises a needed expressive primitive,
On Fri, Nov 9, 2012 at 8:33 AM, Mark S. Miller erig...@google.com wrote:
[...] In my code and in my Q specs
http://wiki.ecmascript.org/doku.php?id=strawman:concurrency and
implementations
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/makeQ.js,
I have been
On 7 November 2012 22:19, Mark S. Miller erig...@google.com wrote:
On Wed, Nov 7, 2012 at 11:12 AM, Andreas Rossberg rossb...@google.com
wrote:
On 7 November 2012 17:57, Tom Van Cutsem tomvc...@gmail.com wrote:
While we're talking nomenclature: the terms promise and future also
appear,
On 12 November 2012 16:43, Mark S. Miller erig...@google.com wrote:
The shift back to when clearly failed to achieve consensus.
FWIW, I think then is better, because when sounds as if it should
be passed some kind of predicate or condition. It just doesn't read
very natural when taking
On Nov 12, 2012, at 1:52 AM, Tom Van Cutsem wrote:
2012/11/12 Allen Wirfs-Brock al...@wirfs-brock.com
It isn't clear to me why the [[HasOwnProperty]] internal method and the
hasOwn Proxy trap need to exist as object behavior extension points.
[...]
let p = new Proxy({}, {
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 functionality of
`has` can (and usually should) be
Rearranging a bit:
* the weight of library authors sending down their own versions of this
stuff is MASSIVE and *should* inform what we do. Any other bias needs massive
justification. So yes, we have tons of validation on this. Just look around.
Q is 3KB compressed, and some of its
2012/11/12 Allen Wirfs-Brock al...@wirfs-brock.com
I think the root issue relates to polymorphic dispatch of the internal
methods and the transparent forwarding of unhanded traps to the Proxy
target object.
Every-time the spec. calls an internal method it is implicitly doing a
polymorphic
2012/11/12 Allen Wirfs-Brock al...@wirfs-brock.com
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
Tom Van Cutsem wrote:
Another potential consistency issue is between [[HasOwnProperty]]
and [[GetOwnProperty]]. That could be eliminated by combining
them into one operation:
[[GetOwnPropety]](name, descriptorNeeded) - descriptor | boolean
| undefined
If
Hi,
Array.prototype.filter could be used to convert sparse to dense array, e.g.
[1,2,3].filter(Boolean.bind(null, true)); //[1, 2, 3]
Would be pretty straightforward if built-in filter could be called without
callback function and returns a dense array.
I guess the engines will optimize
if it's about iterating you have forEach which does not iterate over non
assigned indexes ... this looks like you want a new feature with an ES5
method as filter is so that you can use an ES3 for loop after ...
I mean, you have forEach, map, etc to iterate valid indexes, why would you
need that?
On Nov 12, 2012, at 1:00 PM, Tom Van Cutsem wrote:
2012/11/12 Allen Wirfs-Brock al...@wirfs-brock.com
...
2) can be solved by having the handler subclass the standard Handler (see
http://wiki.ecmascript.org/doku.php?id=harmony:virtual_object_api): by
subclassing the Handler and
Lately I have being struggling with an implementation differences of host (DOM)
objects across the browsers.
So far only reliable way I could find to identify host objects is by a
following assertion:
object.constructor.call === void(0)
Behaviour seems to be consistent across FF, Opera,
On Nov 12, 2012, at 1:59 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
On Nov 12, 2012, at 1:20 PM, Brendan Eich wrote:
Tom Van Cutsem wrote:
Another potential consistency issue is between [[HasOwnProperty]]
and [[GetOwnProperty]]. That could be eliminated by combining
them
Irakli Gozalishvili wrote:
Lately I have being struggling with an implementation differences of
host (DOM) objects across the browsers.
So far only reliable way I could find to identify host objects is by a
following assertion:
object.constructor.call === void(0)
Wow, that's not bad (except
Asen, as mentioned what I meant is that I would sparse.filter(Object); once
if that's about having a repeated iteration.
This let you avoid the Boolean.bind(null, true) if that was the concern but
I have no idea about performances.
There are too many libraries to change in order to support this
In the Oct. ES6 draft you may noticed that there is an editor's comment
attached to each of sections 15.4.4.23-25. These are the definitions of the
items, keys, and values methods on array objects. The note says:Need to
decide whether to allow an argument that requests sparse iteration. In
On Mon, Nov 12, 2012 at 2:12 PM, Irakli Gozalishvili rfo...@gmail.comwrote:
Lately I have being struggling with an implementation differences of host
(DOM) objects across the browsers.
So far only reliable way I could find to identify host objects is by a
following assertion:
On Mon, Nov 12, 2012 at 5:39 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
So the question on the floor: is there any interest in having this
variation of array iteration in ES6?
I would prefer not. Sparse arrays are really rare and for the few cases
these are used I expect the author to
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 bitfield.
const
On Nov 12, 2012, at 3:03 PM, Erik Arvidsson wrote:
On Mon, Nov 12, 2012 at 5:39 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
So the question on the floor: is there any interest in having this variation
of array iteration in ES6?
I would prefer not. Sparse arrays are really rare
On Mon, Nov 12, 2012 at 4:39 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
So the question on the floor: is there any interest in having this
variation of array iteration in ES6?
No. Why complicate the API with a feature just for people who use sparse
arrays on purpose? From what we
Regards
--
Irakli Gozalishvili
Web: http://www.jeditoolkit.com/
On Monday, 2012-11-12 at 14:30 , Brendan Eich wrote:
Irakli Gozalishvili wrote:
Lately I have being struggling with an implementation differences of
host (DOM) objects across the browsers.
So far only reliable way I
this is really easy to fix via code but I would rather propose an
Array#compact() or Array#dense() method rather than changing everything
else (included shims/polyfills)
I really don't remember when it happened last time that I had to deal with
such kind of Arrays ... and this made already every
I've been wondering for a while if it would be a good idea to add an
argument to Array.prototype.filter, for a maximum number of matches. For
example, if I have a thousand-element array and I only want three matches,
it might make sense to truncate the search after the third match.
Put another
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) {
original.length = 0;
}
});
29 matches
Mail list logo
