On Jun 17, 2014, at 1:02 PM, Jason Orendorff wrote:
> On Tue, Jun 17, 2014 at 2:49 PM, Jasper St. Pierre
> wrote:
>> How would
>>
>>constructor() {
>>if (rand() > 0.5)
>>super("A");
>>}
>>
>> behave?
>
> SyntaxError.
>
>> We could prevent this behavior by making s
On Jun 17, 2014, at 1:41 PM, Till Schneidereit wrote:
> On Tue, Jun 17, 2014 at 6:07 PM, Mark Miller wrote:
> I am happy with #b as well, though I prefer #c. I also agree with C. Scott's
> interpretation of #c, to mean, appropriate degenerate value, which is
> generally the zero value, but is
On Jun 17, 2014, at 1:53 PM, Domenic Denicola wrote:
>> It sounds like the the tide is swinging towards bug finding rather than
>> consistency in this case. I'm fine with and and will update the spec.
>> accordingly.
>
> The conclusion here wasn't exactly clear to me. Is it the following?
>
On Jun 17, 2014, at 2:10 AM, Till Schneidereit wrote:
> On Thu, Jun 12, 2014 at 10:42 PM, C. Scott Ananian
> wrote:
> On Thu, Jun 12, 2014 at 3:56 PM, Mark S. Miller wrote:
> > I like this list. I prefer #c.
> > * We have previously succeeded at making previously non-generic methods
> > generi
On Jun 16, 2014, at 3:02 PM, Jason Orendorff wrote:
> On Fri, Jun 13, 2014 at 5:33 AM, Tom Van Cutsem wrote:
>> Interesting. It'd be nice if we could further simplify the Proxy/Reflect
>> API. Given the local nature of these changes, we might still include it in
>> ES6 if we achieve quick consen
On Jun 16, 2014, at 11:29 AM, Michael Zhou wrote:
> Thanks for the clarification, one detail about the order between incrementing
> and setting $$lastIteration_i:
> {
>let i = $$lastIteration_i; //create and initialize per iteration i
>if (!(i<10)) break;
> {
> let i;
>}
>
On Jun 15, 2014, at 11:45 PM, Tom Van Cutsem wrote:
> 2014-06-13 19:21 GMT+02:00 Allen Wirfs-Brock :
> Anotherconcern I have with @@new, it that it exposes two extension points,
> @@new and @@create, on very constructor. I'm afraid that it wouldn't be very
> clear to mo
On Jun 13, 2014, at 1:02 PM, Erik Arvidsson wrote:
> On Fri Jun 13 2014 at 3:41:02 PM, Allen Wirfs-Brock
> wrote:
>
> Hold on. We covered this in one of the face to face meetings and I was of the
> impression it was decided that we should not have a fallback but instead
>
On Jun 13, 2014, at 12:07 PM, Jussi Kalliokoski wrote:
>
>
> function Foo () {}
>
> Foo.prototype[Symbol.create] = null;
@@create methods are normally defined as methods of the constructor function
rather than as an instance method on the prototype. So the above should be:
Foo[Symbol.create
On Jun 13, 2014, at 11:02 AM, Boris Zbarsky wrote:
> On 6/13/14, 1:51 PM, Allen Wirfs-Brock wrote:
>
>> The object you return is an instance of the superclass and not of the
>> subclass.
>
> Ah, right.
>
> So just to make sure, now that I think about it: in t
On Jun 13, 2014, at 7:51 AM, Boris Zbarsky wrote:
> On 6/13/14, 6:33 AM, Tom Van Cutsem wrote:
>> As Allen mentioned, this came up a number of times in TC39 meetings and
>> I believe the fear for exotic objects that require control over
>> [[Construct]] was the biggest show-stopper. If more knowl
On Jun 13, 2014, at 8:05 AM, C. Scott Ananian wrote:
> On Fri, Jun 13, 2014 at 6:33 AM, Tom Van Cutsem wrote:
>> Jason proposes:
>>new C(...args) => C[Symbol.new](...args)
>>
>> Allen proposes:
>> new C(...args) => C.apply(C[Symbol.create](), args)
>
> Consider also the way the spec cou
On Jun 12, 2014, at 5:01 PM, Jeff Walden wrote:
> On 06/12/2014 03:25 PM, Brendan Eich wrote:
>> Actually, if memory serves, IE JScript tolerated null and undefined on right
>> of for-in. SpiderMonkey and my ur-JS implementation, Mocha, did not. Someone
>> with the jwz nostalgia Netscape 2/3 br
On Jun 12, 2014, at 12:50 PM, Michael Zhou wrote:
> In other words, is
> for (let i = 0; i < 10; i++) {
> let i;
> }
>
> legal? I feel it is, but I'm not sure if the specs has made that clear.
> Thanks!
The above is legal according to the current ES6 spec. draft. The let in the
loop body b
On Jun 12, 2014, at 3:18 PM, André Bargull wrote:
> Corrected link: https://bugs.ecmascript.org/show_bug.cgi?id=2737
>
>
> On 6/13/2014 12:16 AM, André Bargull wrote:
>>> On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
>>>
>>> > Somehow I missed when we decided to allow null/undefined as th
On Jun 12, 2014, at 2:36 PM, Erik Arvidsson wrote:
> Somehow I missed when we decided to allow null/undefined as the iterable
> value in for-of loops.
>
> The following test passes using the spec algorithms:
>
> var c = 0;
> for (var x of null) {
> c++;
> }
> assert.equal(c, 0);
>
> However
On Jun 12, 2014, at 12:25 PM, Boris Zbarsky wrote:
> On 6/12/14, 3:21 PM, Allen Wirfs-Brock wrote:
>> simply not knowing whether all of the DOM [[Construct]] semantics could be
>> successfully replaced replaced using only @@create methods and constructor
>> bodies.
On Jun 12, 2014, at 12:14 PM, C. Scott Ananian wrote:
> On Thu, Jun 12, 2014 at 3:06 PM, Till Schneidereit
> wrote:
>> On Thu, Jun 12, 2014 at 8:29 PM, C. Scott Ananian
>> wrote:
>>> (a) `#toString` throws TypeError when given a non-instance. Changes
>>> `Date#toString()`, no change to `Date#t
On Jun 12, 2014, at 11:30 AM, Jason Orendorff wrote:
> On Thu, Jun 12, 2014 at 10:06 AM, Domenic Denicola
> wrote:
>> I'd be most interested in seeing if we can remove IsConstructor entirely
>> (except for uses where it's just a guard, implementing the semantics of
>> `new` via IsConstructor -
On Jun 12, 2014, at 8:57 AM, Erik Arvidsson wrote:
> On Thu Jun 12 2014 at 11:28:12 AM, C. Scott Ananian
> wrote:
> It would be slightly more "JavaScripty" to have
> Date.prototype.[[DateValue]] exist, and be set to the epoch or some
> such.
>
> +1
>
> 1. Let date be the this value.
> 2. If T
On Jun 12, 2014, at 8:45 AM, André Bargull wrote:
>> On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote:
>>
>> > While working on changing Date.prototype to be a plain object in
>> > SpiderMonkey, we realized that there's an issue: the way things are
>> > specced now, `alert(Date.prototype)`
On Jun 12, 2014, at 8:33 AM, André Bargull wrote:
>> I'd be most interested in seeing if we can remove IsConstructor entirely
>> (except for uses where it's just a guard, implementing the semantics of
>> `new` via IsConstructor -> [[Construct]] or throw).
>>
>> It seems like there's at least s
On Jun 12, 2014, at 8:28 AM, C. Scott Ananian wrote:
> It would be slightly more "JavaScripty" to have
> Date.prototype.[[DateValue]] exist, and be set to the epoch or some
> such.
>
> This problem actually seems to be an artifact of the way that
> [[Construct]] works in ES6 -- but the takeaway
On Jun 12, 2014, at 8:30 AM, Erik Arvidsson wrote:
>
> Why can't we "blindly" call `this[[Construct]]`? It will throw for all of the
> above cases which is pretty much what one would expect.
I already said I'd be fine with that. Personally I think the practice of
high-jacking methods and turn
On Jun 12, 2014, at 8:24 AM, Mark Miller wrote:
> On Thu, Jun 12, 2014 at 8:19 AM, Allen Wirfs-Brock
> wrote:
>
> Fortunately there aren't very many of those. I think it is only Date and
> RegExp that have this issue among the ES6 built-ins
>
> WeakMap, Map, Set
her aspects of of subclassing just won't work in ES5.
Allen
>
>
> From: Allen Wirfs-Brock
> Sent: Thursday, June 12, 2014 10:59
> To: Jason Orendorff
> Cc: Domenic Denicola; EcmaScript
> Subject: Re: IsConstructor
>
> On Jun 12, 2014,
On Jun 12, 2014, at 5:26 AM, Till Schneidereit wrote:
> While working on changing Date.prototype to be a plain object in
> SpiderMonkey, we realized that there's an issue: the way things are specced
> now, `alert(Date.prototype)` will throw, because `Date.prototype.toString`
> isn't generic. T
On Jun 12, 2014, at 5:36 AM, Jason Orendorff wrote:
> On Wed, Jun 11, 2014 at 11:44 AM, Allen Wirfs-Brock
> wrote:
>> Array.from and Array.of have a non-throwing IsConstrutor test because they
>> are designed to allow things like this:
>>
>> let of = Array.of;
&g
On Jun 11, 2014, at 11:59 AM, Rick Waldron wrote:
>
>
>
> On Wed, Jun 11, 2014 at 1:37 PM, Domenic Denicola
> wrote:
> It's also deceptive: it makes you think `Array.of` and `Array.from` are
> functions, when in reality they are definitely methods.
>
> Yes, you're right.
>
>
> What about
On Jun 11, 2014, at 11:09 AM, Domenic Denicola wrote:
> From: Allen Wirfs-Brock
>
>> There are a few uses of IsConstructor in some Array methods that deal with
>> subtle backwards compat issues that are a result of extending Array to be
>> subclassable. These are
+02:00 Allen Wirfs-Brock :
>
> Kind of boarder line. 6.1.7.2 says that the "essential internal methods" are
> those listed in Table 5 (does not include [[Call]] and [[Constructor]]).
> Also the definitions of [[Call]] and [[Construct]] in 9.5 each include a note
> that
On Jun 10, 2014, at 9:35 PM, Ian Hickson wrote:
> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
>>
>> No, that's not the intent of the ES design. The EnqueueTask abstract
>> operations takes the name of a specific Job queue as an argument and
>> always pla
On Jun 11, 2014, at 7:24 AM, Domenic Denicola wrote:
> A variety of places in the spec use the new IsConstructor abstract operation.
> In ES5, this test (essentially, "does the object implement the [[Construct]]
> internal method") was restricted to the `new` operator. But in ES6, it is
> used
On Jun 11, 2014, at 8:49 AM, André Bargull wrote:
>
> From [1]:
> ```javascript
> function IsConstructor(o) {
> try {
>new (new Proxy(o, {construct: () => ({})}));
>return true;
> } catch(e) {
>return false;
> }
> }
> ```
>
> This IsConstructor implementation does not trigger any
On Jun 11, 2014, at 8:16 AM, Tom Van Cutsem wrote:
>
> 2014-06-11 16:48 GMT+02:00 Erik Arvidsson :
>
> [*] Proxies are oddballs here. All Proxies have a [[Construct]] method so the
> IsConstructor will always return true which is really not what you want. If
> IsConstructor was changed to che
On Jun 10, 2014, at 7:53 PM, Ian Hickson wrote:
> On Wed, 11 Jun 2014, Domenic Denicola wrote:
>> From: Ian Hickson [mailto:i...@hixie.ch]
>>>
>>> Where in the ES spec are the ES jobs for promises queued up?
>>
>> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-triggerpromisereaction
On Jun 10, 2014, at 7:21 PM, Ian Hickson wrote:
> On Wed, 11 Jun 2014, Domenic Denicola wrote:
>>
>> Hmm. How do we reconcile this with the fact that promises use microtasks
>> in all implementations today? Are they nonconformant with the spec? Or
>> is the spec flexible enough that e.g. Promi
On Jun 10, 2014, at 2:31 PM, Garrett Smith wrote:
> On 6/10/14, Ian Hickson wrote:
>> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
>
> Hi Ian; Allen.
>
>>> (Also, how could step 6's substeps ever get triggered?)
>>>
>>> Working backwards, st
On Jun 10, 2014, at 2:33 PM, Ian Hickson wrote:
> On Tue, 10 Jun 2014, Domenic Denicola wrote:
>>
>> Remember that ES tasks === HTML microtasks (in all implementations
>> today [...]
>
> That doesn't sound right. If every script is always running on an ES task,
> then it sounds like an ES tas
On Jun 10, 2014, at 2:08 PM, Ian Hickson wrote:
> On Tue, 10 Jun 2014, Allen Wirfs-Brock wrote:
>>>
>>> Is my understanding correct that the HTML spec should invoke this
>>> algorithm when the HTML spec creates the Window object?:
>>>
>>>
On Jun 10, 2014, at 11:01 AM, Ian Hickson wrote:
> (I first tried to send this last week, but it seems the es-discuss
> mailman is filtering some of my mail as spam or something?)
>
> Hello,
>
> I've been working with jorendorff to try to write a description of the
> Loader part of the ES6 spec
On Jun 6, 2014, at 6:30 PM, John Lenz wrote:
> Great thanks for the links. I missed or had forgotten the Jan 2014 summary.
> The summary for that discussion is pretty clear that the functions have two
> bindings (a block local one and a function scope one, if it can) and I assume
> that is
On Jun 5, 2014, at 6:25 PM, Brendan Eich wrote:
> LOL - as if O.p has getters!
>
> Thanks, this is more general in case of insanity.
It probably always a good idea to use Reflect.* calls inside of proxy handlers.
I’m seen variants of this mistake in many handlers snippets that are floating
On Jun 5, 2014, at 5:52 PM, Brendan Eich wrote:
> Rick Waldron wrote:
>>
>> * `Object.preventUndeclaredGet()` - change an object's behavior to throw an
>> error if you try to read from a property that doesn't exist (instead of
>> returning `undefine`).
>>
>> This can be achieved with Proxy r
Over and beyond the breaking change WRT function, I really don’t see the value
in such a restriction. There are many pointless or nonsensial things that can
be written as expressions. In general, we don’t complicate the language to
make such things illegal.
Allen
On Jun 5, 2014, at 7:58 A
On Jun 5, 2014, at 8:14 AM, John Lenz wrote:
> On Wed, Jun 4, 2014 at 8:52 PM, Allen Wirfs-Brock
> wrote:
>
> We don’t want to leave the meaning of function declarations in blocks
> completely unspecified, as in ES1-5 as we; know there are legacy
> compatibility requirem
On Jun 4, 2014, at 2:43 PM, John Lenz wrote:
>
>
>
>
>
> How does someone write code to make sure it doesn't fall into legacy
> semantics? Unless, I misunderstand these rules seem like a refactoring
> hazard. It would seem better to say: sloppy mode === no block scoped
> function decla
On Jun 3, 2014, at 3:12 PM, John Lenz wrote:
>
>
>
> On Mon, Jun 2, 2014 at 9:37 AM, Allen Wirfs-Brock
> wrote:
>
> On Jun 2, 2014, at 6:12 PM, John Lenz wrote:
>
> >
> >
> > It seems to imply that existing "sloppy" code that does th
On Jun 2, 2014, at 6:33 PM, Juan Ignacio Dopazo wrote:
> Import/export declarations are designed to be static. However, eval() seems
> to break this invariant:
>
> eval('import ' + foo + ' from ' + bar);
>
> Is this valid ES6 code? Should it be valid?
No and no. In ES6 eval parses the using
On Jun 2, 2014, at 6:12 PM, John Lenz wrote:
>
>
> It seems to imply that existing "sloppy" code that does this is block scope:
>
> for (let x = 1; x < 1; x++) {
> function f() {
> }
> store(f);
> }
>
The above can't be “legacy code” as it contains a “let”. But, I’ll assume you
m
On May 31, 2014, at 8:59 PM, Nicholas C. Zakas
wrote:
> I've been playing around with using destructuring as function arguments and
> have come across some odd behaviors that I'm not sure are intentional (or
> perhaps, not to spec).
Argument binding initialization takes place as part of
htt
Oops, fixed
Michael Dyck wrote:
>On 14-05-22 05:58 PM, Allen Wirfs-Brock wrote:
>> http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#may_22_2014_draft_rev_25
>
>In bugs.ecmascript.org, the "Draft for 6th Edition" Product needs a Version
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#may_22_2014_draft_rev_25
This is mostly a lot of resolved bugs.
Other changes include:
Added Content of 8.5 Initialization (of the ES execution environment)
Additional cleanup/refactoring of Realm initialization
Changed Object
On May 22, 2014, at 9:28 AM, Boris Zbarsky wrote:
> On 5/22/14, 12:16 PM, Allen Wirfs-Brock wrote:
>> Out-of-bounds access have also been observed in non-Emscripten code, for
>> example [1] [2].
>
> Out-of-bounds reads are very common in code that works with canvas imaged
On May 22, 2014, at 4:01 AM, Dmitry Lomov wrote:
>
>
> Wait, am I reading this correctly that after a backing array buffer is
> neutered, accesses to typed arrays within [0...original length) should throw
> and accesses outside that range should continue to return 'undefined'? This
> is defi
On May 21, 2014, at 5:51 PM, Jeremy Martin wrote:
> I think it is better to have one legacy method that behaves differently from
> all the other (new) methods then to maintain consistency by introducing 20+
> new bug farms.
>
> Is it too late (or too unexpected) for aTypedArray.subarray(aNeut
On May 21, 2014, at 10:50 AM, Kenneth Russell wrote:
> On Tue, May 20, 2014 at 5:10 PM, Allen Wirfs-Brock
> wrote:
>>
>> What I propose is that for these new methods we will do a neutered check on
>> entry and immediately throw a TypeError if the this value is a
On May 21, 2014, at 9:59 AM, Dmitry Lomov wrote:
>
>
>
> On Wed, May 21, 2014 at 5:19 PM, Allen Wirfs-Brock
> wrote:
>
> On May 21, 2014, at 2:02 AM, Dmitry Lomov wrote:
>
>>
>> >
>> >> Finally, I note that the current Khronos spec.
On May 21, 2014, at 5:56 AM, Andreas Rossberg wrote:
> On 21 May 2014 14:33, Claude Pache wrote:
>>
>> I have thought about the right semantics (and the issues) of the existential
>> operator.
>>
>>user.getPlan?().value?.score;
>>
>> The intended semantics of `?` is that, whenever its LH
On May 21, 2014, at 2:02 AM, Dmitry Lomov wrote:
>
> >
> >> Finally, I note that the current Khronos spec. doesn't provide much
> >> guidance in this regard. The thing it has that is most similar to the
> >> other array methods is the 'subarray' method and it doesn't explicitly say
> >> anyt
below
On May 20, 2014, at 4:28 PM, Kenneth Russell wrote:
> On Tue, May 20, 2014 at 9:40 AM, Allen Wirfs-Brock
> wrote:
>>
>> On May 20, 2014, at 8:37 AM, Anne van Kesteren wrote:
>>
>>> On Tue, May 20, 2014 at 5:25 PM, Allen Wirfs-Brock
>>> wrote
On May 20, 2014, at 1:10 PM, John Lenz wrote:
> Has there been any discussion about rethrowing exceptions such that they
> retain the original context?
>
> try {
> throws();
> } catch (e) {
> if (e instanceof SomeError) {
> // handle it
> }
> rethrow e;
> }
>
> Or is this been out
On May 20, 2014, at 12:58 PM, Garrett Smith wrote:
> "Prior to the Sixth Edition, the ECMAScript specification did not
> define the occurrence of a FunctionDeclaration as an element of a
> Block statement's StatementList."
>
> The problem is not necessarily that FunctionDeclaration appears in a
On May 20, 2014, at 8:37 AM, Anne van Kesteren wrote:
> On Tue, May 20, 2014 at 5:25 PM, Allen Wirfs-Brock
> wrote:
>> The ES6 TypedArray/ArrayBuffer spec. was written closely following the
>> Khronos spec. which is pretty vague about what happens when an ArrayBuffer
>>
On May 20, 2014, at 7:37 AM, Anne van Kesteren wrote:
> "ArrayBuffer instances whose [[ArrayBufferData]] is null are
> considered to be neutered" However, most algorithms only check for it
> being undefined (and sometimes missing).
The operations on ArrayBuffers all have lines that are the equiv
I've have a serve respect pending with Mozilla IT. I'll see if I can nudge
them.
Allen
On May 15, 2014, at 4:58 AM, Anne van Kesteren wrote:
> On Tue, Apr 29, 2014 at 12:40 AM, Michael Dyck wrote:
>> For the past couple of days, when I create or modify a bug on
>> bugs.ecmascript.org, my brow
On May 8, 2014, at 9:08 PM, Mathias Bynens wrote:
> On Fri, May 9, 2014 at 1:44 AM, John-David Dalton
> wrote:
>> Should I create a spec bug for tracking this?
>
> Please do.
>
Even better, submit a strawman proposal
allen
___
es-discuss mailing l
On May 8, 2014, at 4:05 PM, John-David Dalton wrote:
>
> Thanks for the discussion links, Allen.
> I'm I reading it right that there was no concrete resolution to the issue?
Right, nothing concrete came out of it so won't happen for ES6.
Post-ES6 is always possible.
Allen
On May 8, 2014, at 1:25 PM, John-David Dalton wrote:
> ES6 additions like Object.assign use [[OwnPropertyKeys]] for getting the keys
> of `source` objects. This helps avoid the method gotchas faced by developers
> previously with things like `Object.prototype.writable = true` and
> `Object.def
On May 5, 2014, at 10:40 AM, John Barton wrote:
> I'm hoping someone can explain this result which surprises me.
>
> If I create an object with a Proxy-ed prototype, the resulting object does
> not obey .__proto__ equal Object.getPrototypeOf().
>
> For example:
> var aPrototype = {foo: 'foo'
nscopables for the Object Environment Record is always the empty list. It's
>> never populated.
>>
>>
>>> Allen
>>>
>>> On May 1, 2014, at 3:00 AM, Erik Arvidsson
>>> wrote:
>>>
>>> > This was never resolved
ere
>
> On Wed Sep 25 2013 at 6:17:32 PM, Allen Wirfs-Brock
> wrote:
> So here is another concern, about the scheme we agreed to last week.
>
> It needs to match a found own property against the possibility of an own
> @@unscopable property on the same object and that object ma
On May 1, 2014, at 2:50 AM, Jason Orendorff wrote:
>
> As specified, proxies can do this:
>
> js> Object.isFrozen(proxy)
> true
> js> Object.getOwnPropertyDescriptor(proxy).configurable
> true
No, that is not the intent. However, Object.isFrozen depends upon the
reliability of [[OwnPro
On Apr 30, 2014, at 11:08 AM, Mark S. Miller wrote:
> I'm surprised and alarmed by this, and it seems wrong. It is also not what I
> think I remember. What about, for example, the invariant that an object
> cannot both claim that a property is non-configurable but then later change
> its alle
On Apr 30, 2014, at 8:43 AM, Jason Orendorff wrote:
> The [[Origin]] field of Property Descriptor Records is not yet
> implemented in Firefox. Eric Faust is looking at implementing it.[1]
> We noticed two interesting cases:
>
> 1. Suppose handler.getOwnPropertyDescriptor returns ({value: 0}). T
At
http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#april_27_2014_draft_rev_24
Changes include:
• Several important bug fixes to Function Declaration Instantiation
• Updated RegExp so that subclasses that over-ride exec semantics don’t
have to also over-ride
On Apr 25, 2014, at 11:45 AM, Oliver Hunt wrote:
>
> o = {__proto__: {set foo() {print(“bar”)}}
> o.foo = (o.__defineSetter__(“foo”, function(){ print(“foo”)})), 5
1) o.f evaluates to a Reference whose base is the value of 0 and whose
referenced name is "foo". No lookup occurs at this point.
On Apr 25, 2014, at 10:25 AM, Oliver Hunt wrote:
>
> On Apr 25, 2014, at 4:24 AM, Andreas Rossberg wrote:
>
>> The way destructuring assignment currently is specified leads to
>> rather inconsistent evaluation order. Consider:
>>
>> let o = {}
>> function f() { print(1); return o }
>> functio
On Apr 25, 2014, at 9:44 AM, Rick Waldron wrote:
>
>
>
> On Fri, Apr 25, 2014 at 12:10 PM, Allen Wirfs-Brock
> wrote:
>
> The solution "Outlawing 'yield' in a try-finally", is that _only_ for
> try-finally? What about:
>
On Apr 25, 2014, at 4:53 AM, Kevin Smith wrote:
> It seems to me that generators are not the best mechanism to express resource
> management ("abstract over expensive resources") because the programmer of
> the generator can never guarantee that the consumer will exhaust it. If we
> want dire
On Apr 24, 2014, at 2:33 PM, Mark S. Miller wrote:
> Excellent. Given that, how realistic is the performance concern for the
> non-exceptional situation? Where is the overhead?
the body of the for-of loop could directly or indirectly throw an exception or
contain a break.The break can presumab
On Apr 24, 2014, at 2:33 PM, Mark S. Miller wrote:
> Excellent. Given that, how realistic is the performance concern for the
> non-exceptional situation? Where is the overhead?
the body of the for-of loop could directly or indirectly throw an exception or
contain a break.The break can presumab
On Apr 24, 2014, at 1:29 PM, Brendan Eich wrote:
> Sorry for the confusion -- my "such a change" was about changing @@iterator
> itself, e.g. not defining it on a generator, or trying somehow to guarantee
> freshness.
>
> I agree, return automation makes sense for any delimited form that impli
On Apr 24, 2014, at 12:38 PM, Mark S. Miller wrote:
> I agree that this issue should treat for/of and [...x], etc, similarly.
> Either do both or neither.
>
> Does it alleviate the performance concerns if the .return is only invoked on
> early exit, i.e., before the iterator reports that it is
On Apr 24, 2014, at 12:16 PM, Brendan Eich wrote:
> Jason Orendorff wrote:
>> OnThu, Apr 24, 2014 at 1:38 PM, Allen Wirfs-Brock
>> wrote:
>>> > [...]What we did take seriously was the concern about not running
>>> > generator finally blocks when a
On Apr 24, 2014, at 11:08 AM, Jason Orendorff wrote:
> On Tue, Apr 15, 2014 at 10:24 AM, Andreas Rossberg
> wrote:
>>> JH: Iterators are claiming to Iterables, which is a lie.
>>
>> I argued this very point in the past (after a discussion with Dmitry),
>> but wasn't very successful:
>>
>> htt
On Apr 24, 2014, at 10:24 AM, Brendan Eich wrote:
> Allen Wirfs-Brock wrote:
>> If (and it's still an open question) it make sense semantically to call
>> "return" on for-of initiated generators on unwind, then that is what we
>> should do.
>
&
ld
do. Implementations can catch up, but specified semantics is forever.
Allen
>
> On Thursday, April 24, 2014 4:05:14 AM, Andreas Rossberg
> wrote:
> On 15 April 2014 18:06, Allen Wirfs-Brock wrote:
> >>> AWB: We _could_ add a `return()` method.
> >>> ... It
On Apr 23, 2014, at 8:54 PM, Qantas 94 Heavy wrote:
> We need a deterministic order. What deterministic order do you suggest? Why
> would it be better?
>
> Sorry for the confusion, I completely worded that wrong.
>
> I'm specifically referring to the specification sections 23.2.3.1 and
> 23.2
On Apr 22, 2014, at 8:45 AM, Andreas Rossberg wrote:
> On 22 April 2014 16:52, Allen Wirfs-Brock wrote:
>>
>> On Apr 22, 2014, at 12:02 AM, Andreas Rossberg wrote:
>>
>>> On 19 April 2014 20:14, Allen Wirfs-Brock wrote:
>>>>
>>>> The o
On Apr 22, 2014, at 12:02 AM, Andreas Rossberg wrote:
> On 19 April 2014 20:14, Allen Wirfs-Brock wrote:
>>
>> The ordering I propose is:
>> 1) All array index property keys, in ascending array index numeric order.
>> Followed by:
>> 2) All other string pr
a symbol.
If we didn't know that the web has property creation ordering dependencies I
might have specified sorting the string keys (doesn't require recording
property creation order). However, there is no natural sort order for symbols.
>
> /be
>
> Allen Wirfs-Brock w
On Apr 19, 2014, at 11:14 AM, Allen Wirfs-Brock wrote:
> I'm in the middle of updating the spec. of [[OwnPropertyKeys]] to returns an
> Array rather than an Iterator. While doing this I realized that because
> [[OwnPropertyKeys]] is essentially a new MOP level operati
On Apr 19, 2014, at 11:21 AM, Mark S. Miller wrote:
> Awesome! Please let's do this!
>
> I don't understand the comment about Object.keys, etc. If they continue to be
> specified in terms of [[OwnPropertyKeys]], then they get cleaned up as well,
> which seems good.
Object.keys currently says
I'm in the middle of updating the spec. of [[OwnPropertyKeys]] to returns an
Array rather than an Iterator. While doing this I realized that because
[[OwnPropertyKeys]] is essentially a new MOP level operation we have the
opportunity to precisely define the property key ordering it exposes for
It woulds also be good to create a bugs.ecmascript.org ticket for this. That
will ensure it doesn't get lost
Allen
On Apr 15, 2014, at 8:25 AM, Allen Wirfs-Brock wrote:
> yes, It's on my "get back to soon" list...
>
> Allen
>
> On Apr 14, 2014, at 1
On Apr 15, 2014, at 8:24 AM, Andreas Rossberg wrote:
>
>> Proposal:
>>
>>- for...of always assume generator creation
>>- for...of alwayss terminates generator function
>>
>> Lost in cross talk...
>>
>> NM: If you know that iterable creates a fresh iterator, it's very reasonable
>> to c
yes, It's on my "get back to soon" list...
Allen
On Apr 14, 2014, at 12:36 AM, Andy Wingo wrote:
> Hi,
>
> A re-ping on this issue. Probably the relevant people were distracted
> by TC39 last week.
>
> On Tue 08 Apr 2014 14:47, Andy Wingo writes:
>
>> Hello,
>>
>> The current ES6 draft see
Orendorff
> wrote:
> On Sun, Apr 6, 2014 at 1:41 PM, Allen Wirfs-Brock
> wrote:
> > The April 5, 2014 ECMAScript 6 Draft Specification (Rev23) is now available
> > at
> > http://wiki.ecmascript.org/doku.php?id=harmony:specification_drafts#april_5_2014_d
On Apr 11, 2014, at 10:29 AM, Егор Николаев wrote:
> After firing a bug I read the spec again and realised that Get (O, P) should
> already throw a Error.
> So maybe I am misunderstood this from the beginning.
> In this case section "12.14.5.4 4.b. If Type(v) is not Object, then throw a
> TypeE
601 - 700 of 3206 matches
Mail list logo
