Brendan Eich wrote:
Erik Arvidsson wrote:
We really need to be able to do for-of with arrays and node lists
etc, without having to call .values() on it. It is such a common
operation that we should not tax this further.
Agreed. Consider Peter Norvig's Sudoku solver, which I ported to JS1.7
y
Erik Arvidsson wrote:
We really need to be able to do for-of with arrays and node lists etc,
without having to call .values() on it. It is such a common operation
that we should not tax this further.
Agreed. Consider Peter Norvig's Sudoku solver, which I ported to JS1.7
years ago, ported to E
We really need to be able to do for-of with arrays and node lists etc,
without having to call .values() on it. It is such a common operation that
we should not tax this further.
On Mon, Jun 10, 2013 at 3:32 AM, Andy Wingo wrote:
> On Sun 09 Jun 2013 11:34, Jason Orendorff
> writes:
>
> > I thi
yep, that's awesome ... too bad not a single engine exposed yet such easy
change ever for both V8 and/or SpiderMonkey since everything is already in
place, only the public method exposed to JS is missing (and for V8 I've
already porposed a patch to drop the poison pill but nothing happened ...)
I
On Mon, Jun 10, 2013 at 1:18 AM, Tom Van Cutsem wrote:
> 2013/6/9 Dmitry Soshnikov
>
>>
>> On Jun 8, 2013, at 3:30 AM, Till Schneidereit wrote:
>>
>> > At the last TC39 meeting, an agreement was reached for proxies to
>> support an Invoke trap.
>>
>> Finally (I remember that long thread 2 years
Excellent.
On Jun 10, 2013, at 19:26 , Allen Wirfs-Brock wrote:
> The corresponding text describing [[Configurable]] in the ES6 draft has
> already been updated to clarify that [[Writable]] can always be set to false.
>
> Allen
>
> On Jun 10, 2013, at 4:57 AM, Axel Rauschmayer wrote:
>
>> Th
The corresponding text describing [[Configurable]] in the ES6 draft has already
been updated to clarify that [[Writable]] can always be set to false.
Allen
On Jun 10, 2013, at 4:57 AM, Axel Rauschmayer wrote:
> The ECMAScript 5.1 spec says (8.6.1):
> [[Configurable]]: If false, attempts to dele
Paul Hoffman wrote:
The term "incompatible change" is being used too loosely here. RFC
4627 and the ES spec are currently different. If we simply republished
RFC 4627, it would be an incompatible change from ES. If we publish a
new RFC that says exactly what ES says, it will be an incompatible
The term "incompatible change" is being used too loosely here. RFC 4627 and
the ES spec are currently different. If we simply republished RFC 4627, it
would be an incompatible change from ES. If we publish a new RFC that says
exactly what ES says, it will be an incompatible change from the earlier
On Mon, Jun 10, 2013 at 10:50 AM, medikoo
wrote:
> Object.setPrototypeOf is really needed.
>
>From the meeting notes:
Conclusion: __proto__ is an accessor on Object.prototype. The setter
mutates [[Prototype]]. There is no “poison pill”. We will provide both
Object.setPrototypeOf and std:reflect
Object.setPrototypeOf is really needed.
Use cases for that are as rare as for eval, but exist and are valid.
Currently I work on database engine written in JavaScript, and rely quite
heavily on __proto__.
Once I was asked By David Herman to explain my use cases. I prepared
following gist then: ht
On Sun, Jun 9, 2013 at 1:28 PM, David Bruant wrote:
> For the non-membrane proxy use case... I don't know what to think
> anymore...
I'm not sure what we're trying to do is meaningful in the non-membrane
case. The properties we would like to have are:
* Security - A proxy can wrap an arbitrary
On Mon, Jun 10, 2013 at 5:06 AM, BelleveInvis wrote:
> I think that once an object is created, its prototype should be constant.
>
> And we should add features to implement sub-typing built-in types, like
> Array, since this code exists (found in Zepto):
>
Classes offer exactly that:
class Zept
The fact that [[writable]] can change for a non-configurable property is
definitely intentional, see the state diagram MarkM once put up at <
http://wiki.ecmascript.org/doku.php?id=es3.1:attribute_states&s=diagram>.
Cheers,
Tom
2013/6/10 Axel Rauschmayer
> The ECMAScript 5.1 spec says (8.6.1):
On Sun, Jun 9, 2013 at 6:07 PM, Allen Wirfs-Brock wrote:
I've already updated my working draft with [[Invoke]], but I'm on my way to
> the airport and can't create a digest of the changes right now.
>
> However, they were derived from my earlier experiment which you can see zt
> http://wiki.ecmasc
The ECMAScript 5.1 spec says (8.6.1):
[[Configurable]]: If false, attempts to delete the property, change the
property to be an accessor property, or change its attributes (other than
[[Value]]) will fail.
On the other hand [[DefineOwnProperty]] (8.12.9) allows one to change
writability from tr
>
> I think that once an object is created, its prototype should be constant.
>
While many people would fully agree with you, standardizing __proto__ isn't
about whether it is *needed*, but about it being out in the wild and TC39's
desire to let the EcmaScript standard reflect reality. Which, you
Maybe some new API, like `createPrototypeModified(obj, newPrototype)`, it
copies all eigen-properties of `obj` to a new object with its prototype is
`newPrototype`.
> From: infinte.c...@hotmail.com
> To: es-discuss@mozilla.org
> Subject: Is __proto__ read
I think that once an object is created, its prototype should be constant.
And we should add features to implement sub-typing built-in types, like Array,
since this code exists (found in Zepto):
zepto.Z = function(dom, selector) {
dom = dom || []
dom.__proto__ = $.fn
d
2013/6/9 Juan Ignacio Dopazo
> It seems like the right reasoning. The result of these operations should
> be equivalent:
>
> obj.f();
>
> let f = obj.f;
> f.call(obj);
>
These operations will still be equivalent for:
- a proxy that implements both "get" and "invoke" in a consistent way.
- a prox
2013/6/9 Dmitry Soshnikov
>
> On Jun 8, 2013, at 3:30 AM, Till Schneidereit wrote:
>
> > At the last TC39 meeting, an agreement was reached for proxies to
> support an Invoke trap.
>
> Finally (I remember that long thread 2 years ago when I was advocating for
> it).
>
> Curious what was the reaso
2013/6/9 Brian Di Palma
> On Sun, Jun 9, 2013 at 4:18 PM, Tom Van Cutsem wrote:
> >
> > No, we can't just blindly call GetValue in step 1 as that would lead to
> the
> > "get" trap being invoked on a proxy (which is the wrong trap).
> >
>
> Why can't we have the two traps trigger?
>
Think of in
2013/6/9 David Bruant
> Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
>
>> The question is whether there's a strong need for intercepting these
>> operations. It implies a pretty strong growth of the handler API. And it's
>> not sufficiently general-purpose to also work for exotics that are defin
2013/6/9 David Bruant
> Le 09/06/2013 12:50, David Bruant a écrit :
>
>> Le 09/06/2013 11:37, Tom Van Cutsem a écrit :
>>
>>> For full transparency across isolated object graphs, I think membranes
>>> are still the way to go.
>>>
>> I don't understand that part. A membrane (with shadow targets?)
On Sun 09 Jun 2013 11:34, Jason Orendorff writes:
> I think it's a mistake for iterators not to be iterable.
I agree, FWIW.
I think I would go farther and suggest that _only_ iterators be
iterable. That way, the RHS of a for-of is expected to be an iterator.
In the worst case you end up having
25 matches
Mail list logo
