Re: Set constructor arguments
As long as we don't end up with ambiguous constructor as Array could be ( Array(1) VS Array([1]) ) ... so what if the iterable *is* the value I would like to add() automatically ? If it's about auto magic population with auto magic filtering and ordering of potential duplicated values ( and already too much magic, imo ) I would keep Set.length 0 accepting 0 to N arguments rather than a single one so yes, spread through iterable would be ideal. On the other hand, Map and WeakMap have different relation, based on pairs, and different kind of pairs ( object only or anything ) What if we leave these constructors in peace and let outer wrappers eventually decide what kind of sorcery should be applied during initialization ? :-) br On Wed, Feb 15, 2012 at 3:20 AM, Mark S. Miller erig...@google.com wrote: On Tue, Feb 14, 2012 at 12:23 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: nope, Set does not even accept arguments as it is now ... does it ? Not now. But this thread suggests changing it to do so. I think I agree but don't yet have a strong opinion about whether Set should have a single iteratable parameter or a rest parameter of the individual elements. Relevant question: What should spread (... in a call expression) do when its operand is an iterator or iteratable? Currently spread simple treats its operand as array-like, in which case I think perhaps Set should stick with a single parameter. If we can generalize spread to enumerate the values obtained from an iterator, then I think perhaps Set should go with the spread parameter. Whatever we decide for Set should also guide what we do for Map and WeakMap of course. On Tue, Feb 14, 2012 at 9:20 PM, Dean Landolt d...@deanlandolt.comwrote: On Tue, Feb 14, 2012 at 3:07 PM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: if you accept a single argument, of course, but what if you Set(..[1, 2, 1]) then ? `Set(1, 2, 1)` then? Are you suggesting this should throw? So you'd need to dedupe your arguments before you construct a set with them? Isn't that a primary use case of sets? magic add through Set constructor does not sound good to me On Tue, Feb 14, 2012 at 8:27 PM, Peter Michaux petermich...@gmail.com wrote: On Tue, Feb 14, 2012 at 12:09 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: thinking about the add behavior, where no duplicated values will be added, this argument may cause some logic headache anyway Set([1, 2, 1]) what should happen ? I think that should be a set with one element. The element is an array of length three. Peter ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
set.values().forEach(set.delete, set);
+1 on clear(), a shortcut would be nice
On Wed, Feb 15, 2012 at 6:40 AM, Peter Michaux petermich...@gmail.comwrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
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: set.empty() method
On 15 February 2012 07:47, Mark S. Miller erig...@google.com wrote: clear() is ok. Also, java.util.Map and java.util.Set use clear() so it would also be familiar to many people. Perhaps deleteAll() would be more mnemonic, as its relationship with delete() would be obvious? +1 for deleteAll. Give related names to related operations. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
block scope and function declarations
Hello again ecmascriptians,
There has been some discussion about treating function declarations as
var declarations. While I understand the concerns about
compatibility, I think it will be surprising to programmers.
For example:
function f(x) {
bar(); // ???
for (let y of x) {
function bar() { ... y ... }
bar(); // OK
}
bar(); // ???
}
Here I think it's pretty natural to expect that the FunctionBody of
`bar' has access to lexically scoped binding for `y'. But outside the
block, the function bound to `bar' doesn't have any meaning.
I only see two consistent answers here:
function foo(){} == let foo = function(){}
or
funciton foo(){} == var foo = function(){}
Hoisting the function definition doesn't make sense with block scope.
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
+1 on clear() as it's pithy, understandable, and behaves the same in
Java and Python.
What real benefit comes from drawing this connection between delete()
and deleteAll()? I suspect the everyday programmer won't care, and the
ones who do will look it up.
-Michael A. Smith
On Wed, Feb 15, 2012 at 1:47 AM, Mark S. Miller erig...@google.com wrote:
clear() is ok. Also, java.util.Map and java.util.Set use clear() so it would
also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon a...@ashannon.us wrote:
I'd agree with using clear() and isEmpty() with their respective actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich bren...@mozilla.org wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
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
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
___
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: set.empty() method
Not to backtrack the conversation, but I'm not convinced that delete
should be used to remove an element. Noone's going to ask me, how do I
delete an element from the set?. They're going to ask me, how do I
remove an element?. Also, I'm currently suspicious of any parallels
between deleting a property and removing an element from a set. The whole
point of Set and Map is to provide a collection abstraction independent of
javascript's object model (so as to end the confusion that arises from
their conflation), correct?
Plus, syntax-ignorant tokenizers (like the highlighter on the proposal
page) are going to make delete look pretty weird : )
khs
On Wed, Feb 15, 2012 at 8:07 AM, Michael A. Smith mich...@smith-li.comwrote:
+1 on clear() as it's pithy, understandable, and behaves the same in
Java and Python.
What real benefit comes from drawing this connection between delete()
and deleteAll()? I suspect the everyday programmer won't care, and the
ones who do will look it up.
-Michael A. Smith
On Wed, Feb 15, 2012 at 1:47 AM, Mark S. Miller erig...@google.com
wrote:
clear() is ok. Also, java.util.Map and java.util.Set use clear() so it
would
also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon a...@ashannon.us wrote:
I'd agree with using clear() and isEmpty() with their respective
actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich bren...@mozilla.org
wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
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
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
___
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: block scope and function declarations
On Wed, 2012-02-15 at 12:55 +0100, Andy Wingo wrote:
function f(x) {
bar(); // ???
for (let y of x) {
function bar() { ... y ... }
bar(); // OK
}
bar(); // ???
}
Did I just get wtfjs'd here? Is this `bar' not a source element, and
therefore this is a function expression and not a declaration?
Sheepishly yours,
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
On Wed, Feb 15, 2012 at 8:58 AM, Kevin Smith khs4...@gmail.com wrote:
Not to backtrack the conversation, but I'm not convinced that delete
should be used to remove an element. Noone's going to ask me, how do I
delete an element from the set?. They're going to ask me, how do I
remove an element?.
That's a good point. Just like noone's going to ask how do I put an
element.
add : remove :: put : delete
Also, I'm currently suspicious of any parallels between deleting a
property and removing an element from a set. The whole point of Set and
Map is to provide a collection abstraction independent of javascript's
object model (so as to end the confusion that arises from their
conflation), correct?
This is a good argument in favor of clear as well. You never really want
to clear a typical object, it only really makes sense in the context of
collections.
Plus, syntax-ignorant tokenizers (like the highlighter on the proposal
page) are going to make delete look pretty weird : )
khs
On Wed, Feb 15, 2012 at 8:07 AM, Michael A. Smith
mich...@smith-li.comwrote:
+1 on clear() as it's pithy, understandable, and behaves the same in
Java and Python.
What real benefit comes from drawing this connection between delete()
and deleteAll()? I suspect the everyday programmer won't care, and the
ones who do will look it up.
-Michael A. Smith
On Wed, Feb 15, 2012 at 1:47 AM, Mark S. Miller erig...@google.com
wrote:
clear() is ok. Also, java.util.Map and java.util.Set use clear() so it
would
also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon a...@ashannon.us
wrote:
I'd agree with using clear() and isEmpty() with their respective
actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich bren...@mozilla.org
wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
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
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
___
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
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
On Wed, Feb 15, 2012 at 4:55 AM, Andreas Rossberg rossb...@google.comwrote: On 15 February 2012 07:47, Mark S. Miller erig...@google.com wrote: clear() is ok. Also, java.util.Map and java.util.Set use clear() so it would also be familiar to many people. Perhaps deleteAll() would be more mnemonic, as its relationship with delete() would be obvious? +1 for deleteAll. Give related names to related operations. deleteAll would seem better reserved for deleteAll(Collection), which would remove every element present in the collection. -- John A. Tamplin Software Engineer (GWT), Google ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Wed, Feb 15, 2012 at 3:56 AM, Andrea Giammarchi andrea.giammar...@gmail.com wrote: As long as we don't end up with ambiguous constructor as Array could be ( Array(1) VS Array([1]) ) ... so what if the iterable *is* the value I would like to add() automatically ? Don't use spread on it. If it's about auto magic population with auto magic filtering and ordering of potential duplicated values ( and already too much magic, imo ) I would keep Set.length 0 accepting 0 to N arguments rather than a single one so yes, spread through iterable would be ideal. On the other hand, Map and WeakMap have different relation, based on pairs, and different kind of pairs ( object only or anything ) What if we leave these constructors in peace and let outer wrappers eventually decide what kind of sorcery should be applied during initialization ? :-) I think that's the intent of allowing spread to exhaust an iterator. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Tue, Feb 14, 2012 at 11:49 PM, Brendan Eich bren...@mozilla.org wrote: +1 on ... (spread) exhausting an iterator to expand the iterated values into positional parameters or initialisers. What about infinite generators? Punt on any iterators without a predefined length? Otherwise wouldn't there be some kind of exception akin to a stack overflow? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set iterators
On Feb 14, 2012, at 10:41 PM, Mark S. Miller wrote: On Tue, Feb 14, 2012 at 10:05 PM, Gavin Barraclough barraclo...@apple.com wrote: [...] Mark, Do you think we want strict insertion order, including for numeric index properties? I guess I'm thinking the obvious here ( http://wiki.ecmascript.org/doku.php?id=strawman:enumeration ), but it would seem a simplest for users if there were a single story for iteration order. Great question. I hadn't thought about that in this context, but I do find it attractive. Ironically, this might be less efficient than pure insertion order. But worrying about that too early without measurement or evidence would again be premature. It also accommodates Allen's specialized collection as simply a degenerate case. Cool. I think we need to be clear what we are talking about here. The title of this thread is Set iterators and the ordering discussion started in the context of iterator order for the default Set iterator. The issue of iterating numeric indexed properties doesn't arise for the default Set iterator. The numeric indexed properties questions only arises where we are talking about the default iterator for plain vanilla objects which iterates over properties. In general, objects can provide their own default iterator and defining the scope and order of iteration should be part of defining any object based abstraction. Iteration needs to make sense in terms of the abstraction. The specific choices about iteration made for Sets, Maps, or plain vanilla objects shouldn't be biasing the iteration design of other abstractions. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block scope and function declarations
On Feb 15, 2012, at 3:55 AM, Andy Wingo wrote:
Hello again ecmascriptians,
There has been some discussion about treating function declarations as
var declarations. While I understand the concerns about
compatibility, I think it will be surprising to programmers.
Not really, the intent is that function declarations are lexically scoped to
the closest inclosing block (or function body), just like let. The primary
difference between let and function is that the initialization of a function
binding occurs at the top of the enclosing block
Treating function like var has only been discussed in a couple of contexts.
At the global level function may need to bind like var rather than let for
browser legacy compatibility reasons and in support of multiple top-level
script blocks.
The other var related issue concerning function scoping also relates to legacy
compatibility. ES5 and earlier does not allow for function declarations in
blocks. However, all browser JS implementations do allow such declarations but
they don't agree upon a common semantics. Some treat such function
declarations like var declarations in terms of hoisting. FF does something
that is somewhat similar to let, but not quite the same thing. In general, use
of such function declarations are not interoperable among browsers, but there
are some simple usage patterns that will produce the same results in all
browsers.
At the last TC39 meeting it was hypothesized that the block nested function
declaration patterns that are actually used inoperably on the web would
continue to work if interpreted as lexical (let-like) declarations. On that
basis, we decided that we would go forward with let-like scoping of block
nested functions for all ES6 code. However, we will also experiment with early
implementations to ensure that this does not break the web. If it does, we
will have to revisit the issue and probably only use let-like scoping for
functions within strict mode.
For example:
function f(x) {
bar(); // ???
for (let y of x) {
function bar() { ... y ... }
bar(); // OK
}
bar(); // ???
}
both var references outside of the for-let block result to their bindings in
the scope that surrounds the declaration of f. If that is the global scope,
they probably throw as unresolved references.
Here I think it's pretty natural to expect that the FunctionBody of
`bar' has access to lexically scoped binding for `y'. But outside the
block, the function bound to `bar' doesn't have any meaning.
outer scope reference
I only see two consistent answers here:
function foo(){} == let foo = function(){}
or
funciton foo(){} == var foo = function(){}
Hoisting the function definition doesn't make sense with block scope.
All declarations within a block are hoisted to the top of the block but can
only be validly referenced after they have been initialized. The span between
the top of the block and the point of initialization is called the temporal
dead zone. Function declarations are initialized at the top of the block.
Let and const declaration are initialized when evaluated in statement list
order.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block scope and function declarations
On Feb 15, 2012, at 6:14 AM, Andy Wingo wrote:
On Wed, 2012-02-15 at 12:55 +0100, Andy Wingo wrote:
function f(x) {
bar(); // ???
for (let y of x) {
function bar() { ... y ... }
bar(); // OK
}
bar(); // ???
}
Did I just get wtfjs'd here? Is this `bar' not a source element, and
therefore this is a function expression and not a declaration?
No, in ES5 and earlier the above is not syntactically valid code, blocks
contains StatementLists rather than SourceElements and FunctionDeclaration can
not occur in StatementLists. Nor can a ExpressionStatement begin with an
unparenthesized FunctionExpression. Even ignoring the let, there is no valid
interpratation of the above in unextended ES5.
In ES6, FunctionDeclarations are allowed in StatementLists
Sheepishly yours,
Andy
___
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: Set constructor arguments
Many useful finite generators will not know their length ahead of time, so this would be a poor way to detect finiteness. Infinite generators will always create many hazards of non-termination if provided to contexts expecting finite generators. Similarly looped data structures, if provided to contexts expecting acyclic data structures. For the latter, at least it can be detected (as JSON.stringify does). While we could try to create nominal subtypes FiniteIterator and InfiniteIterator so that iterators can declare their alleged intent, IMO this is overengineering for a rare case. And provides no guarantees anyway. I think we should just live with the non-termination danger. We've been doing so for all other sources of non-termination since Turing ;). On Wed, Feb 15, 2012 at 7:48 AM, Dean Landolt d...@deanlandolt.com wrote: On Tue, Feb 14, 2012 at 11:49 PM, Brendan Eich bren...@mozilla.orgwrote: +1 on ... (spread) exhausting an iterator to expand the iterated values into positional parameters or initialisers. What about infinite generators? Punt on any iterators without a predefined length? Otherwise wouldn't there be some kind of exception akin to a stack overflow? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Feb 15, 2012, at 7:48 AM, Dean Landolt wrote: On Tue, Feb 14, 2012 at 11:49 PM, Brendan Eich bren...@mozilla.org wrote: +1 on ... (spread) exhausting an iterator to expand the iterated values into positional parameters or initialisers. What about infinite generators? Punt on any iterators without a predefined length? Otherwise wouldn't there be some kind of exception akin to a stack overflow? Or just an infinite loop. Every time somebody invokes an abstracted operation there is the possibility that it will never complete. We don't worry about the possibility that a stack overflow or infinite loop could occur in the code that provides the iterator so I don't see why we should worry about that in the code the exhausts the iterator. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: block scope and function declarations
Thanks for the note, Allen. One remaining doubt: On Wed, 2012-02-15 at 09:02 -0800, Allen Wirfs-Brock wrote: At the last TC39 meeting it was hypothesized that the block nested function declaration patterns that are actually used inoperably on the web would continue to work if interpreted as lexical (let-like) declarations. What about conditional function definition? E.g.: https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope#Conditionally_defining_a_function or Oliver's comments here: https://bugs.webkit.org/show_bug.cgi?id=27226#c5 It seems like a valid use case that needs an answer. The answer might be, just use declarations, assignments, and function expressions; dunno. Regards, Andy ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: set.empty() method
I agree and find the add/remove pairing to be winning compared to
add/delete. It dodges the ES3 issue. I'd go for pithy over verb-noun-y
any day, so clear deleteAll. Please, y'all, save us from Java-esque
logorrhea!
/be
Dean Landolt wrote:
On Wed, Feb 15, 2012 at 8:58 AM, Kevin Smith khs4...@gmail.com
mailto:khs4...@gmail.com wrote:
Not to backtrack the conversation, but I'm not convinced that
delete should be used to remove an element. Noone's going to
ask me, how do I delete an element from the set?. They're going
to ask me, how do I remove an element?.
That's a good point. Just like noone's going to ask how do I put an
element.
add : remove :: put : delete
Also, I'm currently suspicious of any parallels between deleting
a property and removing an element from a set. The whole point of
Set and Map is to provide a collection abstraction independent of
javascript's object model (so as to end the confusion that arises
from their conflation), correct?
This is a good argument in favor of clear as well. You never really
want to clear a typical object, it only really makes sense in the
context of collections.
Plus, syntax-ignorant tokenizers (like the highlighter on the
proposal page) are going to make delete look pretty weird : )
khs
On Wed, Feb 15, 2012 at 8:07 AM, Michael A. Smith
mich...@smith-li.com mailto:mich...@smith-li.com wrote:
+1 on clear() as it's pithy, understandable, and behaves the
same in
Java and Python.
What real benefit comes from drawing this connection between
delete()
and deleteAll()? I suspect the everyday programmer won't care,
and the
ones who do will look it up.
-Michael A. Smith
On Wed, Feb 15, 2012 at 1:47 AM, Mark S. Miller
erig...@google.com mailto:erig...@google.com wrote:
clear() is ok. Also, java.util.Map and java.util.Set use
clear() so it would
also be familiar to many people.
Perhaps deleteAll() would be more mnemonic, as its
relationship with
delete() would be obvious?
On Tue, Feb 14, 2012 at 10:39 PM, Adam Shannon
a...@ashannon.us mailto:a...@ashannon.us wrote:
I'd agree with using clear() and isEmpty() with their
respective actions.
On Wed, Feb 15, 2012 at 00:37, Brendan Eich
bren...@mozilla.org mailto:bren...@mozilla.org wrote:
Good idea, but I suggest an unambiguous verb instead of an
adjective-or-verb: clear.
empty is often used for the predicate, in naming
conventions that
eschew
isEmpty and emptyp patterns.
/be
Peter Michaux wrote:
If some piece of code needs to empty a set, it would be
good to do
that in a single call
set.empty();
Otherwise we might be left doing the following which
could be very
inefficient.
set.forEach(function(element) {
set['delete'](element);
});
Peter
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Adam Shannon
Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto:es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
___
es-discuss mailing list
es-discuss@mozilla.org mailto: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
xxx : this.yyy in prototype
I did not find any related subject in discussions or specs so here it is :
var f=function(name) {
this._name=name;
};
f.prototype={
get nodeName() {return this._name},
get tagName() {return this._name},
get anotherNameInvention() {return this._name},
...
set nodeName() {},
set tagName() {},
set anotherNameInvention() {},
...
};
So in that case we have to define several getters and setters for
something that is refering to the same object, slowing down the overall
script execution, it would probably be better to have something like :
f.prototype={
nodeName operator this._name,
tagName operator this._name,
anotherNameInvention operator this._name
...
}
var g=new f('test') -- g.nodeName is equal to g._name
While calling new the operator would indicate that g.nodeName must be
equal to g._name whether _name is a property or a method.
nodeName, tagName, etc could be defined in f but this does not solve the
case if we want them to be inherited properties.
Maybe no operator is required and the default behavior should be the
one described above (what could be the use of declaring something like
xxx : this.yyy in prototype ??? I have never seen it).
Example of use : js w3c dom implementation where objects own a lot of
redundant properties.
Regards
A. Vitte
--
jCore
Email : avi...@jcore.fr
Web :www.jcore.fr
Webble : www.webble.it
Extract Widget Mobile : www.extractwidget.com
BlimpMe! : www.blimpme.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: block scope and function declarations
On Feb 15, 2012, at 9:53 AM, Andy Wingo wrote:
Thanks for the note, Allen.
One remaining doubt:
On Wed, 2012-02-15 at 09:02 -0800, Allen Wirfs-Brock wrote:
At the last TC39 meeting it was hypothesized that the block nested
function declaration patterns that are actually used inoperably on the
web would continue to work if interpreted as lexical (let-like)
declarations.
What about conditional function definition?
E.g.:
https://developer.mozilla.org/en/JavaScript/Reference/Functions_and_function_scope#Conditionally_defining_a_function
or Oliver's comments here:
https://bugs.webkit.org/show_bug.cgi?id=27226#c5
It seems like a valid use case that needs an answer. The answer might
be, just use declarations, assignments, and function expressions;
dunno.
This is precisely what we discussed at the last TC39 meeting.
if (predicate) {
function foo() {alert(true)}
} else {
function foo() {alert(false)}
}
foo();
does not work interoperability among existing browsers. Under the proposed
semantics, the above has a separate block scoped binding for foo in each of the
if clauses and the outer reference would most likely be a reference error.
What does work interoperability is something like
if (predicate) {
function foo() {alert(true)}
foo();
}
//note no else clause with an alternative foo definition and no reference to
foo outside of the block.
If somebody wants to conditionally define a function an appropriate way to do
so would be:
let foo;
if (predicate) {
foo=function foo() {alert(true)};
} else {
foo=function foo() {alert(false)};
}
foo();
or perhaps
function altFoo1() {alert(true)}
function altFoo2() {alert(false)}
let foo;
if (predicate) {
foo=altFoo1};
} else {
foo=altFoo2;
}
foo();
Finally, remember that this is all contingent upon completing web breakage
experiments.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Wed, Feb 15, 2012 at 9:15 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
Or just an infinite loop.
Every time somebody invokes an abstracted operation there is the possibility
that it will never complete.
We don't worry about the possibility that a stack overflow or infinite loop
could occur in the code that provides the iterator so I don't see why we
should worry about that in the code the exhausts the iterator.
Yup. There's no real difference between:
let x = new Set(..someInfiniteIterator);
and:
let x = new Set((function(){while(1){}})());
So let's not worry about it.
~TJ
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Set constructor arguments
On Wed, Feb 15, 2012 at 12:13 PM, Mark S. Miller erig...@google.com wrote: Many useful finite generators will not know their length ahead of time, so this would be a poor way to detect finiteness. Yes but you can count the times you've iterated and punt when exceeding `length`, like a poor man's stack depth hint. But yeah, pretty hacky. Infinite generators will always create many hazards of non-termination if provided to contexts expecting finite generators. Similarly looped data structures, if provided to contexts expecting acyclic data structures. For the latter, at least it can be detected (as JSON.stringify does). While we could try to create nominal subtypes FiniteIterator and InfiniteIterator so that iterators can declare their alleged intent, IMO this is overengineering for a rare case. And provides no guarantees anyway. I think we should just live with the non-termination danger. We've been doing so for all other sources of non-termination since Turing ;). True. But this is a little different -- syntactically, spread doesn't exactly scream I'm calling an arbitrary, potentially non-terminating function, but neither do getters. But I'm sure we'll survive. On Wed, Feb 15, 2012 at 7:48 AM, Dean Landolt d...@deanlandolt.comwrote: On Tue, Feb 14, 2012 at 11:49 PM, Brendan Eich bren...@mozilla.orgwrote: +1 on ... (spread) exhausting an iterator to expand the iterated values into positional parameters or initialisers. What about infinite generators? Punt on any iterators without a predefined length? Otherwise wouldn't there be some kind of exception akin to a stack overflow? -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
method modifiers in addition to bind
Since »Function.prototype.bind« did make it into ECMAScript's 5th Edition, how about having implemented prototypal method modifiers »before«, »after« and »around« into next Versions of JavaScript? And in particular for »around«, what should the arguments precedence of the around wrapping function look like? Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: method modifiers in addition to bind
that looks like a wrap to me ... what's the connection with bind() exactly? Also not sure you are talking about dispatched Events (before, around, after) or some other topic br On Thu, Feb 16, 2012 at 1:05 AM, Peter Seliger peter.seli...@googlemail.com wrote: Since »Function.prototype.bind« did make it into ECMAScript's 5th Edition, how about having implemented prototypal method modifiers »before«, »after« and »around« into next Versions of JavaScript? And in particular for »around«, what should the arguments precedence of the around wrapping function look like? Peter ___ 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: method modifiers in addition to bind
that looks like a wrap to me ... what's the connection with bind() exactly? Also not sure you are talking about dispatched Events (before, around, after) or some other topic Sorry for not having pointed it out clearly enough. I'm talking about before/after/around as they are known from Aspect Oriented Programming. The connection to bind, I thought, was that all of them do modify other methods. Therefore I did choose the above subject instead of mentioning AOP in the first place. Peter ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
set.reset method
I don't know how rich the committee wants to make objects in ES.next.
For example, what about a set.reset method?
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.reset method
Sorry. Incomplete message before and premature send.
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
this.add(arguments[i]);
}
};
Peter
On Wed, Feb 15, 2012 at 10:39 PM, Peter Michaux petermich...@gmail.com wrote:
I don't know how rich the committee wants to make objects in ES.next.
For example, what about a set.reset method?
Set.prototype.reset = function() {
this.empty();
for (var i = 0, ilen = arguments.length; i ilen; i++) {
}
}
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
set.add and set.delete arguments
Can set.add and set.delete take multiple arguments? This would go
nicely with the spread of operation on an iterate that was discussed
for multiple arguments to the Set constructor.
var set0 = new Set('alpha', 'beta');
set0.add('gamma', 'delta');
var set1 = new Set('epsilon', 'zeta');
set0.add(...set1);
set0.count; // 6
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: set.add and set.delete arguments
If add and delete take multiple arguments, the return value could be
changed from a boolean to the number of elements added or deleted, or
to the set of elements added or deleted?
Peter
On Wed, Feb 15, 2012 at 10:54 PM, Peter Michaux petermich...@gmail.com wrote:
Can set.add and set.delete take multiple arguments? This would go
nicely with the spread of operation on an iterate that was discussed
for multiple arguments to the Set constructor.
var set0 = new Set('alpha', 'beta');
set0.add('gamma', 'delta');
var set1 = new Set('epsilon', 'zeta');
set0.add(...set1);
set0.count; // 6
Peter
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
