C. Scott Ananian wrote:
On Wed, Sep 24, 2014 at 2:36 AM, Viktor Mukhachevesdiscus...@yandex.ru wrote:
RegExp.prototype.exec returns array with extra properties (input, index),
may be it is better to return something other for `run`, frozen value object with
`0`, `1`, ... keys for example.
Hi Fabrice,
Thanks for the proposal, I ran it by TC39 yesterday and it advanced to
stage 0. This means work getting to stage 1, per:
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaVUF7Dk0hpPpPDzU/edit
The committee liked it not only for emulating int64 and uint64 more
Brendan Eich wrote:
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it in sooner, but TC39 wanted less
sooner based on library usage. There was a
On Wed, Sep 24, 2014 at 2:56 PM, Brendan Eich bren...@mozilla.org wrote:
Brendan Eich wrote:
Tab Atkins Jr. wrote:
This works great as a general principle, but honestly tons of
languages have already forged this path. It's pretty straightforward,
I think.
I made the case for building it
On Wed, Sep 24, 2014 at 5:37 PM, Brendan Eich bren...@mozilla.org wrote:
Hi Fabrice,
Thanks for the proposal, I ran it by TC39 yesterday and it advanced to
stage 0. This means work getting to stage 1, per:
https://docs.google.com/document/d/1QbEE0BsO4lvl7NFTn5WXWeiEIBfaV
Agreed with Tab, in terms of composing inherited functionality it's hard to
beat prototypal and the ease of `Class.prototype.__noSuchProperty__ =
function(){ ... };` traitish approach.
I also think Proxy already gives us a way to work around the
`__noSuchProperty__` issue
On Wed, Sep 24, 2014 at
Tab Atkins Jr. wrote:
Using subclassing to bung in some arbitrary trait is really terrible.
:/ It requires either adding it up high in your class hierarchy, or
having to write a custom NoSuchPropertyClass which extends your
superclass, so you can then extend it.
Ok, let's not hand-wave mixin
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-createresolvingfunctions
Each resolving function R uses R.[[AlreadyResolved]].[[value]] to prevent the
same promise from being resolved twice.
Question: Couldn’t R.[[Promise]].[[PromiseState]] be used, instead?
--
Dr. Axel Rauschmayer
Figured it out: This is needed for “locking in”.
Quoting [1]:
A promise is _resolved_ if it is settled or if it has been locked in to
match the state of another promise. Attempting to resolve or reject a
resolved promise has no effect.
[1]
9 matches
Mail list logo
