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,
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
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
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 bzbar...@mit.edu wrote:
On 3/6/14 6:15 PM, Joshua Bell
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
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
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
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
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 wray...@gmail.com wrote:
Additionally, .contains() can be used in a conditional
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
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
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
On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock al...@wirfs-brock.com 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
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
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.
On 7/23/14, Maël Nison 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.
So too, for cases of removing an item,
On Jul 23, 2014, at 9:51 AM, Andy Wingo wrote:
On Wed 23 Jul 2014 18:19, Allen Wirfs-Brock al...@wirfs-brock.com 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
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.
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
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
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
On Wed, Jul 23, 2014 at 11:18 AM, es-discuss-requ...@mozilla.org 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
Array.prototype.removeAt(index);
Array.prototype.remove(element);
On Wed, Jul 23, 2014 at 3:12 PM, Alex Vincent ajvinc...@gmail.com wrote:
On Wed, Jul 23, 2014 at 11:18 AM, es-discuss-requ...@mozilla.org wrote:
So too, for cases of removing an item, would Array.prototype.remove(v)
show
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
On Wed, Jul 23, 2014 at 2:00 PM, Michael Haufe t...@thenewobjective.com
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
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
On 7/23/14, Andrea Giammarchi andrea.giammar...@gmail.com 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
27 matches
Mail list logo
