Re: Array.prototype.contains

[Garrett Smith]

On 7/23/14, Andrea Giammarchi  wrote:
> agreed, already imagining loops like
>
> ```js
> while (arr.contains(value)) arr.remove(value);
> ```
>
> although that looks a bit nicer than
>
> ```js
> var i;
> while (-1 < (i = arr.indexOf(value))) arr.splice(i, 1);
> ```
>
> my main concern about `.contains()` is its potentially un-optimal
> implementation and error prone logic.
>
> Most of the time we want to know if an array contains something to avoid
> duplicated because we are missing `.unique()`
>
> ```js
> if (!arr.contains(obj)) arr.push(obj);
> ```
>
> Most other times we want to do some action with that contained value or its
> index and here we have a redundant and error prone cases:
>
> ```js
> if (arr.contains(obj)) {
>   // need the index anyway
>   var i = arr.indexOf(obj); // but this might fail 
>   // splice or do other things ...
> }
> ```
>
> AFAIR the latter `.contains()` does not suffer same problems `.indexOf()`
> does and this will result in incompatible operations with array indexes,
> assuming contains told us we are good to go.
>
> As example, `.contains(NaN)` can cause disaster-prone logics if followed by
> `.indexOf(NaN)` because the first check will tell the developer at runtime
> for sure something was there while the second check will return a lovely -1
> most likely unexpected inside the block that believe `.contains(value)` was
> a safe bet.
>


// Contains NaN:
[1, NaN, ].some(function(e) {return Number.isNaN(e);})
-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Andrea Giammarchi]

agreed, already imagining loops like

```js
while (arr.contains(value)) arr.remove(value);
```

although that looks a bit nicer than

```js
var i;
while (-1 < (i = arr.indexOf(value))) arr.splice(i, 1);
```

my main concern about `.contains()` is its potentially un-optimal
implementation and error prone logic.

Most of the time we want to know if an array contains something to avoid
duplicated because we are missing `.unique()`

```js
if (!arr.contains(obj)) arr.push(obj);
```

Most other times we want to do some action with that contained value or its
index and here we have a redundant and error prone cases:

```js
if (arr.contains(obj)) {
  // need the index anyway
  var i = arr.indexOf(obj); // but this might fail 
  // splice or do other things ...
}
```

AFAIR the latter `.contains()` does not suffer same problems `.indexOf()`
does and this will result in incompatible operations with array indexes,
assuming contains told us we are good to go.

As example, `.contains(NaN)` can cause disaster-prone logics if followed by
`.indexOf(NaN)` because the first check will tell the developer at runtime
for sure something was there while the second check will return a lovely -1
most likely unexpected inside the block that believe `.contains(value)` was
a safe bet.

Just my 2 cents on an issue I see coming soon on your screens

Regards




On Wed, Jul 23, 2014 at 2:05 PM, Alex Vincent  wrote:

> On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe 
> wrote:
>
>> Array.prototype.removeAt(index);
>> Array.prototype.remove(element);
>>
>
> We already have an equivalent of removeAt:  Array.prototype.splice(index,
> 1).  My concern about remove still stands.
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Alex Vincent]

On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe 
wrote:

> Array.prototype.removeAt(index);
> Array.prototype.remove(element);
>

We already have an equivalent of removeAt:  Array.prototype.splice(index,
1).  My concern about remove still stands.

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Allen Wirfs-Brock]

On Jul 23, 2014, at 12:54 PM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> Also, I find some of these questions seem simpler to reason about I think in 
>> terms of an iterator with 'next', 'throw' and 'return' methods rather than a 
>> generator and its various internal states.
> 
> The loop forms are "external iteration" 
> (http://esdiscuss.org/topic/generators-vs-foreach) and any throw or return 
> within the body should not propagate a useful value to the generator 
> implementation of the iterator (if any). The contract is based only on 
> .next().
> 
> Reifying control effects as exceptions or implicitly invoked methods needs a 
> strong rationale. Implicit is worse than explicit. Now is not the time to 
> invent without extant use cases.

I agree, for-of shouldn't do implicit throws() to its iterator, just return().  
However yield* has been specified for a long time to implicitly propagate a 
throw() to the outer generator into as a throw() to the inner iterator.  Maybe 
that made sense in the absence of return() but now that we have return ().  
yield* is really just a loop that the throw() is terminating early.  From that 
perspective it seens we should invoke return() and not throw on the inner 
iterator.

allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Michael Haufe]

Array.prototype.removeAt(index);
Array.prototype.remove(element);



On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent  wrote:

> On Wed, Jul 23, 2014 at 11:18 AM,  wrote:
>
>> So too, for cases of removing an item, would Array.prototype.remove(v)
>> show clear intent.
>>
>
> I would actually raise a concern about that method.  Suppose v shows up in
> the array more than once.  Do you remove the first appearance, the last, or
> all of them?
>
> --
> "The first step in confirming there is a bug in someone else's work is
> confirming there are no bugs in your own."
> -- Alexander J. Vincent, June 30, 2001
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Alex Vincent]

On Wed, Jul 23, 2014 at 11:18 AM,  wrote:

> So too, for cases of removing an item, would Array.prototype.remove(v)
> show clear intent.
>

I would actually raise a concern about that method.  Suppose v shows up in
the array more than once.  Do you remove the first appearance, the last, or
all of them?

-- 
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Allen Wirfs-Brock]

On Jul 23, 2014, at 11:21 AM, Jeremy Martin wrote:

> Now that we have return() it isn't clear to me that we actually need throw()
> 
> Am I understanding correctly that you're suggesting removing throw from 
> Generator.prototype?
> 
> If so, I'd like to suggest that, at a minimum, .throw() has been rather 
> useful in the context of Node.js control-flow libraries [1] that surface 
> "catchable" asynchronous errors.
> 
> [1] https://github.com/jmar777/suspend#error-handling
> 

I see, your example is using generators like the first perspective I described 
in my response to Brendan.  The generator is essentially in control and sees 
the 'yield' as a call to an operation for which it is prepared to handle 
exceptions. It's logically splicing together two call chains. Essentially using 
a generator as a co-routine.

Ok, I buy that throw() is useful for that use case.  I still think it is a 
different from the looping control structure case where the loop is in control 
rather than the iterator.

Allen___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Allen Wirfs-Brock]

On Jul 23, 2014, at 11:12 AM, Brendan Eich wrote:

> Allen Wirfs-Brock wrote:
>> Now that we have return() it isn't clear to me that we actually need throw() 
>> or whether for-of/yield* should call throw() like they currently do.
> 
> Wait, throw is useful anyway, for exception-throwing apart from returning. 
> Right?
> 
> Also I do not know what you mean by "like they currently do".
> 
> I hope this is all pre-caffeine confusion on my part!
> 
> /be
> 

Here's what I'm trying to say:

for (let each of aGenerator) {
 return 42;
}

I think we all agree, that the loop implicitly show do a:
   aGenerator.return(42);  //or perhaps just: aGenerator.return() ??

but what about:

for (let each of aGenerator) {
 throw new Error;
}

Do we do:
  aGenerator.throw(theErrorExceptionObject);  //propagate all unhanded 
exceptions that terminated the loop to the generator
or
  aGenerator.return(); //unwind the generator because the loop is abnormally 
terminating, then propagate the exception

The current spec. draft does the first of these, but I'm not totally convinced 
that is the better alternative.

To me, it seems to come down to how yo think about the generator in 
relationship to its clients.

If you think about it from the perspective of the generator, then one model is 
that a |yield| is really just a callback into the client loop and the generator 
would expect its exception handlers to catch unhanded exceptions generated 
within the callback. 

If you think about it from the perspective of the loop, the generator is just 
an (iterator) object on which you are performing 'next' method calls.  There is 
no particular reason that you would expect an exception occurring in the loop 
body (or from the loop mechanism) to propagate to the iterator object (or any 
other known object) as it isn't in the current call chain.  But if the loop 
abnormally terminates by an unhandled exception you still want to "close" the 
iterator by invoking its 'return' method.

yield* is similar to a loop, in that (as currently specified) it propagates a 
throw() delivered to the outer generator to the inner iterator. Does this 
really make sense?  What relevance is that exception to the inner iterator?  
Why shouldn't yield * just call return() on the inner iterator to "close" it?

So going back to my original questions.  Given that we now have return() 
available to close an abnormally discarded generator, when would somebody 
(presumably implementing a control abstraction) actually want to apply throw() 
rather than return() to an iterator?

catch and finally are really two quite different things.  Catch is a 
dynamically scoped mechanism for finding exception handlers.  Finally, is a 
unwind mechanism for cleaning up local invariants when a function activation is 
abnormally terminated. It's clear, to me, why a control abstraction would want 
to unwind a generator (ie return()) it is discarding.  It's less clear (at 
least seemingly a lot less common) for a control abstraction to want to splice 
into the exception handling of a generator).

I guess what I need to see are some motivating user cases for generator throw() 
where throw is really what is needed rather than return();

Finally, when thinking about these issue if find that 'close' does seem to be a 
more appropriate name than 'return'.  The mechanism is based upon using a 
'return' completion value, but the callers intent seems to be 'close the 
iterator'  (or unwind the iterator).   

Also, I find some of these questions seem simpler to reason about I think in 
terms of an iterator with 'next', 'throw' and 'return' methods rather than a 
generator and its various internal states.  

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Jeremy Martin]

>
> Now that we have return() it isn't clear to me that we actually need
> throw()


Am I understanding correctly that you're suggesting removing throw from
Generator.prototype?

If so, I'd like to suggest that, at a minimum, .throw() has been rather
useful in the context of Node.js control-flow libraries [1] that surface
"catchable" asynchronous errors.

[1] https://github.com/jmar777/suspend#error-handling


On Wed, Jul 23, 2014 at 1:52 PM, Allen Wirfs-Brock 
wrote:

>
> On Jul 23, 2014, at 9:51 AM, Andy Wingo wrote:
>
> On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock 
> writes:
>
> On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:
>
>
>The TC39 notes do not record any discussion of return() causing an
>
>exception to be thrown.
>
>
>
> In the latest ES6 draft for-of propagates any exceptions thrown by the
>
> call to return(). See
>
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-
>
> forin-div-ofbodyevaluation step 3.k.ii.1-2
>
>
> As a matter of design policy we rarely, if ever, just drop exceptions.
>
>
> I probably didn't explain myself completely; apologies.  I meant that
> the mechanism of iter.return() should be implemented by throwing an
> exception (i.e., as if by "iter.throw(new StopIteration)") instead of
> "returning" from the yield point.
>
>
> Well, in ES6 we don't define iterator termination in terms of a
> StopIteration exception.
>
> However, both gen.throw and gen.return are specified in terms of abnormal
> completion of a yield:
>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.return
>
>
> https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.throw
>
> so they both unwind in a similar manner.
>
> consider:
>
> function gen() {
> try {
>while (true) {
>try {yield foo()
>} catch (e) {
>   console.log("throw");
>   throw (e);
>};
> }
> } finally {
>   console.log("unwind");
> };
> }
>
> var  g = gen();
> g.next();
> g.throw(new Error);  //logs: throw, unwind
> var h = gen();
> h.next();
> h.return(); //logs: unwind
>
> Now that we have return() it isn't clear to me that we actually need
> throw() or whether for-of/yield* should call throw() like they currently do.
>
> This is something I hope to discuss at the upcoming TC39 meeting.
>
> Allen
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Boris Zbarsky]

On 7/23/14, 1:29 PM, Allen Wirfs-Brock wrote:

Earlier in this thread we were originally talking about "event handler content 
attributers" and the possibility of doing something in ES Annex B to help define 
them.  But if they are WebIDL exotic functions then maybe that doesn't make so much sense.


No, no.  They're actual honest to God ES functions.  You can get them 
from page script and call them as functions, etc.  And we need to define 
how those ES functions are created given the input, which is a string 
for the function body.


It's just that during event dispatch they're invoked via a Web IDL 
EventHandler which handles things like invoking their [[Call]] and the like.



My sense is that what we are missing is an "architecture" that actually defines 
how HTML and ES integrates.


Yep.

-Boris

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Allen Wirfs-Brock]

On Jul 23, 2014, at 9:51 AM, Andy Wingo wrote:

> On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock  writes:
> 
>> On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:
>> 
>>The TC39 notes do not record any discussion of return() causing an
>>exception to be thrown.
>> 
>> 
>> In the latest ES6 draft for-of propagates any exceptions thrown by the
>> call to return(). See
>> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-
>> forin-div-ofbodyevaluation step 3.k.ii.1-2 
>> 
>> As a matter of design policy we rarely, if ever, just drop exceptions.
> 
> I probably didn't explain myself completely; apologies.  I meant that
> the mechanism of iter.return() should be implemented by throwing an
> exception (i.e., as if by "iter.throw(new StopIteration)") instead of
> "returning" from the yield point.

Well, in ES6 we don't define iterator termination in terms of a StopIteration 
exception.

However, both gen.throw and gen.return are specified in terms of abnormal 
completion of a yield:
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.return
   
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-generator.prototype.throw
 
so they both unwind in a similar manner.

consider:

function gen() {
try {
   while (true) {
   try {yield foo()
   } catch (e) {
  console.log("throw");
  throw (e);
   };
}
} finally {
  console.log("unwind");
};
}

var  g = gen();
g.next();
g.throw(new Error);  //logs: throw, unwind
var h = gen();
h.next();
h.return(); //logs: unwind

Now that we have return() it isn't clear to me that we actually need throw() or 
whether for-of/yield* should call throw() like they currently do.

This is something I hope to discuss at the upcoming TC39 meeting.

Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Garrett Smith]

On 7/23/14, Maël Nison  wrote:
> Isn't replacing DOMStringList a different issue than adding
> Array.prototype.contains ?
>
> Using indexOf is possible, but a .contains() method would give a stronger
> notice of intent when reading code.
>

So too, for cases of removing an item, would Array.prototype.remove(v)
show clear intent.

>
> On 7 March 2014 15:11, Boris Zbarsky  wrote:
>
>> On 3/6/14 6:15 PM, Joshua Bell wrote:
>>
>>> FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
>>> Location.ancestorOrigins
>>>
>>
>> Indeed.  And Location.ancestorOrigins is fairly new and not broadly
>> implemented, so I don't expect its behavior to be a strong compat
>> constraint.
>>
>> So I guess that leaves us with a few questions:
>>
>> 1)  Is it still early enough in the indexeddb world that we can change
>> the
>> thing it uses from DOMStringList to Array.  And if so whether that's a
>> change we want to make.
>>
>> 2)  If we want to keep the non-writing behavior for indexeddb or for some
>> other reason (insufficiently flexible bindings systems?) can't switch ti
>> to
>> Array for now, can we just remove item() and contains() from
>> DOMStringList
>> to make the switch easier later?
>>
>>
>> -Boris
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Maël Nison (arcanis )
> Frontend Developer @ Sketchfab
>


-- 
Garrett
@xkit
ChordCycles.com
garretts.github.io
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Ian Hickson]

On Tue, 22 Jul 2014, Allen Wirfs-Brock wrote:
> > 
> > Do you have any opinion on how I should handle attribute event 
> > handlers? They are conceptually FunctionBodys with specific 
> > parameters, and they are parsed the first time they are invoked, but 
> > can be reinvoked later without being reparsed. Currently the HTML spec 
> > hand-waves this using "code entry points" but those don't really map 
> > to anything in ES.

(Just to clarify: the text in the HTML spec right now is clearly bogus and 
needs rewriting. My questions here are just an attempt to find out what it 
should be rewritten to.)


> You say: "Event Handler content attributes ... match the FunctionBody 
> production after automatic semicolon insertion."  Are you trying to say 
> something special about ASI,.  For example, that ASI is not applied when 
> parsing attribute event handlers.  Or are you just saying that the 
> normal rules of ASI apply.

I mean that you take the FunctionBody production, adjust it to include the 
logic for automatic semicolon insertion, and then that's what an Event 
Handler content attribute needs to match. Note that the text you quote 
here is a document conformance criteria, not a user-agent conformance 
criteria, so it doesn't imply anything about what browsers do.


> If the latter, than you probably don't need to say anything because ASI 
> is part of the ES parsing process.

What I'm trying to say in the text you quote is whether or not something 
is valid. I can't just say that it has to match the FunctionBody 
production, because when ES parses it inserts semicolons, so the strings 
don't always actually match the productions per se. I could also phrase it 
using terminology more like what ScriptEvaluationJob step 2 does, would 
that be better? I'd ideally like to avoid having to mention either 
semicolons or early errors or any of that stuff.


> Also, you defined "internal raw uncompiled handler" as containing a 
> "uncompiled script body".  However, in the ES6 spec. ScriptBody is an 
> actual grammar production that is different from FunctionBody.

"uncompiled script body" is an opaque term unrelated to "ScriptBody".


> I notice that you currently (step 8 of getting current value of event 
> handler) you parse the function body in isolation from a function 
> expression header.  You can't really do that in ES6 as there are early 
> error rules at the level of FunctionExpression that need to be 
> considered with the body. I think, you need to wrap the FunctionBody 
> with the boilerplate source code of a FunctionExpression, including an 
> appropriate formal parameter list.

I can't do that, because that would enable people to do things like end 
their code with a "//" and have it comment out the trailing "}", or put a 
"} function () {" in the middle of their code and have it somehow parsed 
into two functions, or whatnot. In general I think trying to take the 
author's input and manipulate it ends up being a really dangerous 
practice. Better to imply it somehow in prose, IMHO.


> And even with that I'm still uncomfortable will how you are trying to 
> manually wireup the scope of the function using the body.

Me too.


> Perhaps a way out of this is to for Annex B of ES6 
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-additional-ecmascript-features-for-web-browsers
>  
> to actually define the syntax and semantics of an AttributeEventHandler 
> function and provide abstract the operations you can call to create one.

That would be fantastic, sure! Is that an option?


> I imagine that we would want to process the creation of these functions 
> similar to an eval call where we synchronously parse/compile and do not 
> go through the async ScriptEvaluationJob mechanism.

Well, the difficult thing here is that the parsing and the execution have 
to be quite separate. The parsing has to happen just once. If it happens 
as part of event handling, then that will also involve execution; but it 
can also happen as part of just the author getting the value of the 
handler. In either case, if the value is subsequently fetched, the same 
Function object must be returned each time. Also, when creating the 
Function object it's important that we construct the lexical scope 
carefully, and the arguments differ based on context.

When it comes to executing it, it should just be equivalent to normal 
browser-to-script function callbacks.

If you can provide a mechanism that parses the function body, I'd be happy 
to defer to it. The inputs to this would be the string to parse as the 
function body, the names of the argument(s), and a Lexical Environment. 
The output would be a Function object or an error.


> I didn't see where in the process of invoking an event handler that you 
> call the [[Call]] internal method of the callback function.

That's the open issue that says "In this step, invoke means to run the 
jump to a code entry-point algorithm". The "jump to a code entry-point" 
algorithm

Re: The "initialization" steps for Web browsers

[Allen Wirfs-Brock]

On Jul 23, 2014, at 9:52 AM, Boris Zbarsky wrote:

> On 7/23/14, 12:45 PM, Allen Wirfs-Brock wrote:
>> Yes, but how does that then map into the ES invocation model.  If even 
>> handlers are just ordinary ES functions with an ordinary [[Call]]
> 
> They're not.  They're Web IDL callback objects constructed from such ES 
> functions.  So this would be handled by 
> http://heycam.github.io/webidl/#es-invoking-callback-functions and the 
> "callback context" bits it talks about, I would htink.

Earlier in this thread we were originally talking about "event handler content 
attributers" and the possibility of doing something in ES Annex B to help 
define them.  But if they are WebIDL exotic functions then maybe that doesn't 
make so much sense. 

> 
>> I added [[HostDefined]] to jobs after we had a conversation that I believe 
>> was about maintaining a dynamic stack of script origins as code executes. At 
>> the time, you indicated tht you thought it was a sufficient hook. Do you 
>> still think that?
> 
> I think so, yes
> 
>> It's not clear to me how what we are discussing now relates to that.
> 
> Me neither, honestly.  :(  There are too many pieces here, all of them 
> changing in parallel, and I'm not quite sure how they fit together right this 
> second.  :(  I'm hoping Ian is keeping track of all of them and will figure 
> out how they interact.
> 

My sense is that what we are missing is an "architecture" that actually defines 
how HTML and ES integrates.

Allen


___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Andy Wingo]

On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock  writes:

> On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:
>
> The TC39 notes do not record any discussion of return() causing an
> exception to be thrown.
> 
>
> In the latest ES6 draft for-of propagates any exceptions thrown by the
> call to return(). See
> http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-
> forin-div-ofbodyevaluation step 3.k.ii.1-2 
>
> As a matter of design policy we rarely, if ever, just drop exceptions.

I probably didn't explain myself completely; apologies.  I meant that
the mechanism of iter.return() should be implemented by throwing an
exception (i.e., as if by "iter.throw(new StopIteration)") instead of
"returning" from the yield point.

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Boris Zbarsky]

On 7/23/14, 12:45 PM, Allen Wirfs-Brock wrote:

Yes, but how does that then map into the ES invocation model.  If even handlers 
are just ordinary ES functions with an ordinary [[Call]]


They're not.  They're Web IDL callback objects constructed from such ES 
functions.  So this would be handled by 
http://heycam.github.io/webidl/#es-invoking-callback-functions and the 
"callback context" bits it talks about, I would htink.



I added [[HostDefined]] to jobs after we had a conversation that I believe was 
about maintaining a dynamic stack of script origins as code executes. At the 
time, you indicated tht you thought it was a sufficient hook. Do you still 
think that?


I think so, yes


 It's not clear to me how what we are discussing now relates to that.


Me neither, honestly.  :(  There are too many pieces here, all of them 
changing in parallel, and I'm not quite sure how they fit together right 
this second.  :(  I'm hoping Ian is keeping track of all of them and 
will figure out how they interact.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Allen Wirfs-Brock]

On Jul 23, 2014, at 9:31 AM, Boris Zbarsky wrote:

> On 7/23/14, 12:02 PM, Allen Wirfs-Brock wrote:
>> No, synchronous dispatchEvent looks like it could just work depending
>> upon  how the browser specific contextual state (origin, etc. scripting
>> settings, etc. in the HTML spec.) is modeled.
> 
> It's modeled as "settings objects" (settings records, if you prefer). Mostly. 
>  "origin" and "effective script origin" are computed from stuff in the 
> settings record.
> 
>> If dispatchEvent is going to synchronously dispatch event handlers it may
>> have to do browser context switch for each handler.  How does it know to
>> do this?
> 
> Web IDL callbacks store the info they need to set up the call.
> 
>> Perhaps we also need a [[HostDefined]] field in Realm records?
>> (Each function is associated with a realm, so it is a good place to put
>> context that is shared by all functions for a specific realm).


Yes, but how does that then map into the ES invocation model.  If even handlers 
are just ordinary ES functions with an ordinary [[Call]] how do you ensure that 
the  necessary browser context is established when they are invoked from an 
arbitrary place?

> 
> In practice, each Realm has a unique global and the HTML spec ends up hanging 
> its stuff off there as far as I can tell.
> 

I added [[HostDefined]] to jobs after we had a conversation that I believe was 
about maintaining a dynamic stack of script origins as code executes. At the 
time, you indicated tht you thought it was a sufficient hook. Do you still 
think that?  It's not clear to me how what we are discussing now relates to 
that.

Allen

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Array.prototype.contains

[Domenic Denicola]

Yes. Everyone agrees .contains is good. It will happen.

There was some debate about .has vs. .contains, but from what I recall I was 
one of the only people pushing for .has, and I have since changed my mind.

I am hopeful in fact that .contains is so simple and uncontroversial that we 
can push it through the post-ES6 spec process very quickly, including into 
implementations.

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Will Ray
Sent: Wednesday, July 23, 2014 12:42
To: Maël Nison
Cc: Brendan Eich; es-discuss@mozilla.org
Subject: Re: Array.prototype.contains

Additionally, .contains() can be used in a conditional statement directly, 
while .indexOf() requires the result of a comparison with -1 (or a bitwise 
inversion, which is not terribly intuitive). It's just more room for simple 
typos.

Will Ray

On Wed, Jul 23, 2014 at 5:29 AM, Maël Nison 
mailto:nison.m...@gmail.com>> wrote:
Isn't replacing DOMStringList a different issue than adding 
Array.prototype.contains ?

Using indexOf is possible, but a .contains() method would give a stronger 
notice of intent when reading code.

On 7 March 2014 15:11, Boris Zbarsky 
mailto:bzbar...@mit.edu>> wrote:
On 3/6/14 6:15 PM, Joshua Bell wrote:
FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
Location.ancestorOrigins

Indeed.  And Location.ancestorOrigins is fairly new and not broadly 
implemented, so I don't expect its behavior to be a strong compat constraint.

So I guess that leaves us with a few questions:

1)  Is it still early enough in the indexeddb world that we can change the 
thing it uses from DOMStringList to Array.  And if so whether that's a change 
we want to make.

2)  If we want to keep the non-writing behavior for indexeddb or for some other 
reason (insufficiently flexible bindings systems?) can't switch ti to Array for 
now, can we just remove item() and contains() from DOMStringList to make the 
switch easier later?


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss



--
Maël Nison (arcanis)
Frontend Developer @ Sketchfab



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Rick Waldron]

Array.prototype.contains has been approved for the ES7 process:
https://github.com/rwaldron/tc39-notes/blob/master/es6/2014-04/apr-9.md#45-arrayprototypecontains

Rick


On Wed, Jul 23, 2014 at 12:41 PM, Will Ray  wrote:

> Additionally, .contains() can be used in a conditional statement directly,
> while .indexOf() requires the result of a comparison with -1 (or a bitwise
> inversion, which is not terribly intuitive). It's just more room for simple
> typos.
>
> Will Ray
>
>
> On Wed, Jul 23, 2014 at 5:29 AM, Maël Nison  wrote:
>
>> Isn't replacing DOMStringList a different issue than adding
>> Array.prototype.contains ?
>>
>> Using indexOf is possible, but a .contains() method would give a stronger
>> notice of intent when reading code.
>>
>>
>> On 7 March 2014 15:11, Boris Zbarsky  wrote:
>>
>>> On 3/6/14 6:15 PM, Joshua Bell wrote:
>>>
 FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
 Location.ancestorOrigins

>>>
>>> Indeed.  And Location.ancestorOrigins is fairly new and not broadly
>>> implemented, so I don't expect its behavior to be a strong compat
>>> constraint.
>>>
>>> So I guess that leaves us with a few questions:
>>>
>>> 1)  Is it still early enough in the indexeddb world that we can change
>>> the thing it uses from DOMStringList to Array.  And if so whether that's a
>>> change we want to make.
>>>
>>> 2)  If we want to keep the non-writing behavior for indexeddb or for
>>> some other reason (insufficiently flexible bindings systems?) can't switch
>>> ti to Array for now, can we just remove item() and contains() from
>>> DOMStringList to make the switch easier later?
>>>
>>>
>>> -Boris
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>> Maël Nison (arcanis )
>> Frontend Developer @ Sketchfab
>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Will Ray]

Additionally, .contains() can be used in a conditional statement directly,
while .indexOf() requires the result of a comparison with -1 (or a bitwise
inversion, which is not terribly intuitive). It's just more room for simple
typos.

Will Ray


On Wed, Jul 23, 2014 at 5:29 AM, Maël Nison  wrote:

> Isn't replacing DOMStringList a different issue than adding
> Array.prototype.contains ?
>
> Using indexOf is possible, but a .contains() method would give a stronger
> notice of intent when reading code.
>
>
> On 7 March 2014 15:11, Boris Zbarsky  wrote:
>
>> On 3/6/14 6:15 PM, Joshua Bell wrote:
>>
>>> FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
>>> Location.ancestorOrigins
>>>
>>
>> Indeed.  And Location.ancestorOrigins is fairly new and not broadly
>> implemented, so I don't expect its behavior to be a strong compat
>> constraint.
>>
>> So I guess that leaves us with a few questions:
>>
>> 1)  Is it still early enough in the indexeddb world that we can change
>> the thing it uses from DOMStringList to Array.  And if so whether that's a
>> change we want to make.
>>
>> 2)  If we want to keep the non-writing behavior for indexeddb or for some
>> other reason (insufficiently flexible bindings systems?) can't switch ti to
>> Array for now, can we just remove item() and contains() from DOMStringList
>> to make the switch easier later?
>>
>>
>> -Boris
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
>
> --
> Maël Nison (arcanis )
> Frontend Developer @ Sketchfab
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Boris Zbarsky]

On 7/23/14, 12:02 PM, Allen Wirfs-Brock wrote:

No, synchronous dispatchEvent looks like it could just work depending
upon  how the browser specific contextual state (origin, etc. scripting
settings, etc. in the HTML spec.) is modeled.


It's modeled as "settings objects" (settings records, if you prefer). 
Mostly.  "origin" and "effective script origin" are computed from stuff 
in the settings record.



If dispatchEvent is going to synchronously dispatch event handlers it may
have to do browser context switch for each handler.  How does it know to
do this?


Web IDL callbacks store the info they need to set up the call.


Perhaps we also need a [[HostDefined]] field in Realm records?
(Each function is associated with a realm, so it is a good place to put
context that is shared by all functions for a specific realm).


In practice, each Realm has a unique global and the HTML spec ends up 
hanging its stuff off there as far as I can tell.


-Boris
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Allen Wirfs-Brock]

On Jul 23, 2014, at 1:25 AM, Andy Wingo wrote:

> Hi,
> 
> The TC39 notes do not record any discussion of return() causing an
> exception to be thrown.

In the latest ES6 draft for-of propagates any exceptions thrown by the call to 
return(). See 
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-runtime-semantics-forin-div-ofbodyevaluation
 step 3.k.ii.1-2  


As a matter of design policy we rarely, if ever, just drop exceptions.


> 
> I understand that one of the concerns was about guards and catch blocks,
> but making return() throw an exception does not affect that in the
> least.
> 
> It's already the case that any catch block may see any old exception.
> Adding a new kind of exception doesn't affect that; properly written
> catch blocks have to test the positive presence of the exception they
> are looking for, not the absence of exceptions they aren't interested
> in.  Magical return() is no better here because, as you note, return can
> be caught too.
> 
> There are valid cases in which you can have a catch without a guard;
> these are when can enumerate the possible exceptions that a part of your
> program will throw.  However this condition necessarily limits the size
> of the try{} block -- it is unlikely to contain a yield.  So no problem
> there either.

It's not exactly clear to me what your point is here.  If you want to catch any 
exception (including those originating from a return() call to  the iterator) 
that can occur within while executing a for-of statement you would code:

try {
  for (let each of expr) {...}
} catch (e) {... };

If you only want to catch exceptions from the for-of body you would code:

for (let each of expr) {
   try { ...
  }  catch (e) { ...};
}
   

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: The "initialization" steps for Web browsers

[Allen Wirfs-Brock]

On Jul 22, 2014, at 7:14 PM, Boris Zbarsky wrote:
> 
>> BTW, I'm also assuming that a batch of events would be
>> handled as a single ES job
> 
> Hmm... event dispatch can happen synchronously from script like so:
> 
>  target.dispatchEvent(new Event("foo"));
> 
> which will trigger all event listeners for "foo" on the target before the 
> dispatchEvent call returns.
> 
> So we're starting out in an ES job here; are you saying the dispatchEvent 
> call creates a new one?

No, synchronous dispatchEvent looks like it could just work depending upon  how 
the browser specific contextual state (origin, etc. scripting settings, etc. in 
the HTML spec.) is modeled.   Currently we have a [[HostDefined]] field in a 
Job record where, based on a previous conversation, you could stash that state 
when running a script.  If dispatchEvent is going to synchronously dispatch 
event handlers it may have to do browser context switch for each handler.  How 
does it know to do this?  Perhaps we also need a [[HostDefined]] field in Realm 
records? (Each function is associated with a realm, so it is a good place to 
put context that is shared by all functions for a specific realm).

In my original comment above I was thinking about handling asynchronous events. 
I was assuming that you would create a separate job that would fire the 
handlers triggered async events. 

Allen



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Array.prototype.contains

[Maël Nison]

Isn't replacing DOMStringList a different issue than adding
Array.prototype.contains ?

Using indexOf is possible, but a .contains() method would give a stronger
notice of intent when reading code.


On 7 March 2014 15:11, Boris Zbarsky  wrote:

> On 3/6/14 6:15 PM, Joshua Bell wrote:
>
>> FWIW, Blink uses DOMStringList only in IndexedDB and apparently in
>> Location.ancestorOrigins
>>
>
> Indeed.  And Location.ancestorOrigins is fairly new and not broadly
> implemented, so I don't expect its behavior to be a strong compat
> constraint.
>
> So I guess that leaves us with a few questions:
>
> 1)  Is it still early enough in the indexeddb world that we can change the
> thing it uses from DOMStringList to Array.  And if so whether that's a
> change we want to make.
>
> 2)  If we want to keep the non-writing behavior for indexeddb or for some
> other reason (insufficiently flexible bindings systems?) can't switch ti to
> Array for now, can we just remove item() and contains() from DOMStringList
> to make the switch easier later?
>
>
> -Boris
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>



-- 
Maël Nison (arcanis )
Frontend Developer @ Sketchfab
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Generator return() and exceptions

[Andy Wingo]

Apologies for the duplicate mail, how goofy of me.  The second one was
the edit I wanted but they are the same.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Generator return() and exceptions

[Andy Wingo]

Hi,

The TC39 notes do not record any discussion of return() causing an
exception to be thrown.

I understand that one of the concerns was about guards and catch blocks,
but making return() throw an exception does not affect that in the
least.

It's already the case that any catch block may see any old exception.
Adding a new kind of exception doesn't affect that; properly written
catch blocks have to test the positive presence of the exception they
are looking for, not the absence of exceptions they aren't interested
in.  Magical return() is no better here because, as you note, return can
be caught too.

There are valid cases in which you can have a catch without a guard;
these are when can enumerate the possible exceptions that a part of your
program will throw.  However this condition necessarily limits the size
of the try{} block -- it is unlikely to contain a yield.  So no problem
there either.

WDYT?  I really really really do not want magical returns.

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Generator return() and exceptions

[Andy Wingo]

Hi,

At one point I suggested privately that the return() method should throw
a specified exception instead of causing a "return".  The TC39 notes
from the last meeting do not record any discussion of this.

I understand that one of the concerns about this approach was about
guards and catch blocks, but making return() throw an exception does not
affect that in the least: it's already the case that any catch block may
see any old exception.  Adding a new kind of exception doesn't affect
that; properly written catch blocks have to test the positive presence
of the exception they are looking for, not the absence of exceptions
they aren't interested in.  Magical return() is no better here because,
as you note, return can be caught too.

There are valid cases in which you can have a catch without a guard;
these are when can enumerate the possible exceptions that a part of your
program will throw.  However this condition necessarily limits the size
of the try{} block -- it is unlikely to contain a yield.  So no problem
there either.

Magical returns seem unnecessary to me.

Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss