Re: please add orEqual operator
I was going to suggest a Set, now that ECMA has them…
http://www.ecma-international.org/ecma-262/6.0/index.html#sec-set-objects
```js
if ((new Set([1,2,3,5]).has(a)) {
// stuff
}
```
On Sun, Aug 9, 2015 at 4:20 PM myemailu...@gmail.com wrote:
it could be used like this:
if ( a == 1 ||= 2 ||=3 ||=5) { //do something if a is either 1,2,3,5}
and it could be used like this
a || = 0
// a = a || 0
thanks
___
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: try without catch or finally
Why is the argument and curly brace syntax required for except? Why
not simply allow:
try {
throw ExceptionalException;
} catch dosubroutine();
which for the convenience of Jussi's original ask:
try {
//fail
} catch null;
(or if you prefer, a noop call). The lack of parentheses make it clear
that the word following 'except' is not the error parameter, and the
lack of braces clearly means the catch-phrase ends at the semicolon.
It could even be immediately followed by a finally, which I think
yields some terse, but useful syntax that's intuitive and consistent.
try foo();
catch bar();
finally cleanUp();
in the same spirit as
if (foo) doFoo();
else doBar();
-Michael A. Smith
On Wed, Apr 18, 2012 at 5:45 AM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Silent catch-alls like that are almost always bad code. I think the
language rather shouldn't encourage this pattern with extra
convenience.
I don't see how this would be much more encouraging than allowing for the
catch block to do nothing. The people who would use this would leave the
catch block empty anyway.
I am also perplexed as to how often things are countered with similar
arguments. Incompetent programmers make bad decisions regardless of how much
the language/framework/library does to prevent this. In my mind it's not a
valid excuse for not making things harder for those who know what they're
doing. (And I'm in no way claiming to be a competent developer, this is just
an opinion :])
/Andreas
___
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
+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 constructor arguments
…But we wouldn't want to require the arguments to the set constructor
to require instantiation itself/themselves, right? If a set has to be
constructed with an Iterable, and cannot (also) be constructed with
individual atoms, then you'll end up with use cases like Set(['foo',
'bar', 'baz']), which requires two constructions, one of which is
essentially a waste. If allowing both forms of the constructor is
distasteful, then why not just go with the multiple parameters,
approach, and implement toSet() as a method on appropriate Iterables?
-Michael A. Smith
On Sun, Feb 12, 2012 at 9:29 PM, Erik Arvidsson
erik.arvids...@gmail.com wrote:
The default argument should probably just be an iterable.
On Feb 12, 2012 4:50 PM, Oliver Hunt oli...@apple.com wrote:
I saw a reference to it being modified to take an array(-like?) as a
parameter. While I can see an argument in favour of a single array argument
I can also see using a set of parameters that initially populate the set.
We just shouldn't allow both (and introduce another version of the horror
that is the Array constructor).
With the existence of the spread operator I think that there's a good
argument in favour of the multiple parameters approach.
--Oliver
On Feb 12, 2012, at 4:33 PM, Peter Michaux wrote:
In the proposal, the Set constructor takes no arguments.
http://wiki.ecmascript.org/doku.php?id=harmony:simple_maps_and_sets
Could it take a list of initial elements to be included in the set?
var s = new Set('alpha', 'beta');
s.has('alpha'); // true
I think this is a lot better than the verbosity that is
var s = new Set();
s.add('alpha');
s.add('beta');
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
___
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 extras functionality for iterators
Sorry for the resend. Meant to include the list. I like this idea a lot! However, what would be the correct behavior of a method like 'every' on an infinite generator? -Michael A. Smith On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola dome...@domenicdenicola.com wrote: ES5's existing array extras make working with arrays a joy. However, sometimes arrays are not the right tool for the job. Perhaps you want lazy evaluation semantics (generators). Or perhaps you want to communicate that the list is immutable (compare .NET's `IEnumerableT` or Java's `IterableT`). ES Harmony seems to have the answer: iterators! Like `IEnumerableT` or `IterableT`, they are the most basic primitive of iteration. Yay! But, if my `fetchAllProducts()` method returns an iterator, I don't get my array extras. Sad. --- This may be solvable in library-space, but the iterator proposal doesn't seem to have an Iterator.prototype I could extend. So we end up with unfortunate underscore-style wrappers: _(iterator).chain().map(mapper).some(predicate).value() _.some(_.map(iterator, mapper), predicate) I propose adding the array extras to any iterator (in some way), such that we can have syntax similar to the following: iterator.map(mapper).some(predicate) // returns an iterator The methods I would like to see are: * every, filter, forEach, map, reduce, reduceRight, some * Optionally: join, toString * Controversially: sorted, reversed (non-mutating versions of sort and reverse) What do you think? -Domenic ___ 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 extras functionality for iterators
On a related note, there are many ways in which some of these methods would overlap with the capabilities of array comprehensions and generator expressions. As far as I can tell, the one thing you cannot do (with, say, map) is take an array as input and process it lazily. For example: someVeryLargeArray.map(someFunction); // guarantees an array result, cannot be lazy vs (someFunction(someVeryLargeArray(i), i, someVeryLargeArray) for (i in someVeryLargeArray)) // Lazy, likely to perform better in some important cases. I think there's a case to be made for direct implementations of such methods. Something like someVeryLargeArray.iMap(someFunction); // Lazy, guaranteed only to be iterable (No apologies to the email protocol.) What do you think? -Michael A. Smith On Fri, Feb 3, 2012 at 3:54 PM, Domenic Denicola dome...@domenicdenicola.com wrote: iterator.map(mapper).some(predicate) // returns an iterator The methods I would like to see are: * every, filter, forEach, map, reduce, reduceRight, some * Optionally: join, toString * Controversially: sorted, reversed (non-mutating versions of sort and reverse) What do you think? -Domenic ___ 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.range() (was: Suggestion: Array.prototype.repeat)
When I first started learning JavaScript I didn't understand how
new Array(n);
worked, in that it creates an empty array with a length of n. What I
had expected was an array with n values (even if it wasn't
well-defined what those values should be). So of course my attempt to
create an array of random numbers:
var rands = (new Array(6)).map(function () { return
Math.floor(Math.random() * (1001)) }; );
fell flat. This is one case where the earlier Array.prototype.repeat
proposal had merit. Either way I think the Array.prototype.range
suggestion is useful, but I wish it could generate an array with
arbitrary values. Maybe we could create a shortcut syntax instead of
requiring .map if the *value* parameter in Adam's proposal could
alternatively be a callback? (Is it safe to assume nobody wants to use
range to create an array of functions? Maybe not, but it would surely
be useful.)
Michael A. Smith
Web Developer
True Action Network, an eBay Company
On Tue, Jan 3, 2012 at 1:12 PM, Rick Waldron waldron.r...@gmail.com wrote:
On Tue, Jan 3, 2012 at 12:50 PM, Sean Eagan seaneag...@gmail.com wrote:
I think step should be 0, and step towards end:
Array.range({start: 5, end: 0, step: 2}) - 5, 3, 1
This would be an unfortunate limitation, considering real world impl's allow
negative numbers...
http://documentcloud.github.com/underscore/#range
On Tue, Jan 3, 2012 at 11:42 AM, Axel Rauschmayer a...@rauschma.de
wrote:
I think it's fairly common for range implementations to provide an
optional
`step` parameter
Good point. Maybe all of these parameters should be options:
Array.range() - 0, 1, 2, 3, ...
Array.range({ start: 3 }) - 3, 4, 5, 6, ...
Array.range({ end: 5 }) - 0, 1, 2, 3, 4
Array.range({ step: 3 }) - 0, 3, 6, 9, ...
Array.range({ start: -2, step: -1 }) - -2, -3, -4, -5, ...
etc.
The defaults of start and end and the comparison operator depend on the
sign
of step.
--
Dr. Axel Rauschmayer
a...@rauschma.de
home: rauschma.de
twitter: twitter.com/rauschma
blog: 2ality.com
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Sean Eagan
___
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: String.prototype.until
Semantically, calling it until makes me think that if the needle
isn't found, it should return the entire haystack. Your example
implementation would return an empty string in that case. Also, to
keep consistency with other string methods like substr, shouldn't we
allow the developer to decide the starting index?
String.prototype.until = function (start, needle) {
return + (this.substr(start, this.indexOf(needle)) || this);
}
(The [ +] part is probably not necessary, but it makes it easier to
see the implementation work in the console.)
Michael A. Smith
Web Developer
True Action Network (an eBay Company)
On Mon, Jan 2, 2012 at 12:03 PM, Adam Shannon a...@ashannon.us wrote:
Hello all,
I recently ran into a situation where I would like to obtain a
substring from the beginning until the first encounter with another
substring. This promoted me to write a simple function, called until
and I wondered if it would be something to add with the other string
extras for ES.next.
It could be defined as acting the same way as the following code:
String.prototype.until = function (needle) {
return this.substr(0, this.indexOf(needle));
}
--
Adam Shannon
Web Developer
University of Northern Iowa
Sophomore -- Computer Science B.S. Mathematics
http://ashannon.us
___
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: Suggestion: Array.prototype.repeat
On Mon, Jan 2, 2012 at 3:56 PM, Mariusz Nowak medikoo+mozilla@medikoo.com wrote: I like it, it indeed looks very logical, however it's a bit controversial that we need to create temporary array object to get one that we want. Function (not method) that returns generated array may make more sense… Is the difference in overhead between instantiating a new array and using Array.prototype.slice.call on arguments really worth sacrificing consistency with the proposed string.prototype.repeat and the very clean syntax of someArray.repeat(n)? Michael A. Smith Web Developer True Action Network (an eBay company) ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
