Re: generators vs forEach
Hello,
On Wed 17 Jul 2013 10:50, Claus Reinke claus.rei...@talk21.com writes:
// this doesn't work
function* generator(){
[1,2,3].forEach( function(x){ yield x } )
}
For the specific case of forEach et al
What do you mean by et al? I don't believe .map, .reduce or .filter
are any interesting to use alongside generators.
And why not? Because yield is a statement
Yield is an expression.
Why shouldn't I be able to traverse an array, using the ES5 standard
operations for doing so, yielding intermediate results from the
traversal (recall also that yield can return data sent in via .next,
for incorporation into such traversals)?
You certainly can, with one modification: using *ES6* standard
operations (external iterators vs the ES5 forEach internal iterator).
Generators and non-generator iterators and for-of and comprehensions
hang together really nicely in practice.
function* g(){
for(x of [1,2,3]) yield transform(x);
}
Methods can be replaced by built-ins. It is the reverse that
is now broken.
Au contraire, but it requires a re-think on your part: favor external
iterators over internal iterators.
Andy
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Frozen Date objects?
And if it ever goes back to the drawing board, make it immutable of course and please remember that months are numbered from 1 to 12! ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Array.prototype.values breaks the web
We've had to back out Array.prototype.values for the second time now, because it breaks every website that uses Sencha's Ext.js. See [1], [2] and [3]. In [4], Don from Sencha says that they're investigating, but also that even once they fix the issue, (obviously) it's going to take some time for all users to upgrade. These users include all commercial Ext.js users (banking websites[1] and Synology's NAS web interfaces among them), every Typo3 installation, and most certainly lots of other open source projects. Searching for ext.js on github gets some 7000 hits. Given that, I don't see how we can expect to be able to land Array.prototype.values in any meaningful timeframe and think dropping it or changing the name should be considered. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=883914 [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=892225 [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=881782 [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=883914#c15 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.values breaks the web
On 7/23/2013 9:00 AM, Till Schneidereit wrote: Given that, I don't see how we can expect to be able to land Array.prototype.values in any meaningful timeframe and think dropping it or changing the name should be considered. Bikeshed time! I submit vals and items. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.values breaks the web
First, I think we should question adding plain-named methods to long-standard prototypes. Second, we should avoid cybercruddy names. Third, we should be careful to break common pairings such as key and value. Where does this leave us? I'm thinking close to wanting a functional API, generic keys, values, entries (nee items), with any method delegation using symbol-named @keys, @values, @entries. /be Brandon Benvie wrote: On 7/23/2013 9:00 AM, Till Schneidereit wrote: Given that, I don't see how we can expect to be able to land Array.prototype.values in any meaningful timeframe and think dropping it or changing the name should be considered. Bikeshed time! I submit vals and items. ___ 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: How primitive are Symbols? Bignums? etc
Brendan Eich wrote:
I think this goes in the wrong direction. 'new' implies heap
allocation and reference-type semantics. Value objects do not have
either.
Previously, from Claude Pache in April:
https://mail.mozilla.org/pipermail/es-discuss/2013-April/029750.html
The idea is simply to avoid adding footguns for new features, even if we can't
remove the existing ones.
Regarding the issue discussed here, let me elaborate:
Until now, `new Primitive`, where `Primitive` is `Number`, `String` or
`Boolean` is, in practice, not a problem, because you never need to create a
new number, string or boolean that way. (You can use `Primitive` as a function
for typecasting, but it is not felt as the same thing as creating a new value.)
Things are different with symbols, so the `new Symbol` footgun is practically a
new type of footgun.
Note also that `new Date`, `new RegExp`, `new Map`, etc., work as intuitively expected,
and, if I have correctly followed the last discussions, `function* gen() { /* ... */};
myIterator = new gen` (meaning: I want to get a *new* iterator from that generator
function) would also work.
I do agree that special-casing should be avoided. Therefore, I think we should
make a rule: `new Primitive` should throw for primitive types, except for
legacy numbers, booleans and strings (Don't Break The Web) for which it is not
a real issue.
—Claude
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Array.prototype.values breaks the web
I've added the subject to the agenda Rick On Tue, Jul 23, 2013 at 1:11 PM, Brendan Eich bren...@mozilla.com wrote: First, I think we should question adding plain-named methods to long-standard prototypes. Second, we should avoid cybercruddy names. Third, we should be careful to break common pairings such as key and value. Where does this leave us? I'm thinking close to wanting a functional API, generic keys, values, entries (nee items), with any method delegation using symbol-named @keys, @values, @entries. /be Brandon Benvie wrote: On 7/23/2013 9:00 AM, Till Schneidereit wrote: Given that, I don't see how we can expect to be able to land Array.prototype.values in any meaningful timeframe and think dropping it or changing the name should be considered. Bikeshed time! I submit vals and items. __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss __**_ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/**listinfo/es-discusshttps://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
var n = 0O755; Is this something anyone wants to read? I certainly don't! Allowing only lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on balance I think that's probably preferable to admitting this monstrosity. :-) (Which isn't to say I care strongly enough to spend a whole bunch of time arguing the point, only enough to raise it as a concern and see if others agree.) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
FWIW, I d0On't like it neither On Tue, Jul 23, 2013 at 12:04 PM, Jeff Walden jwalden...@mit.edu wrote: var n = 0O755; Is this something anyone wants to read? I certainly don't! Allowing only lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on balance I think that's probably preferable to admitting this monstrosity. :-) (Which isn't to say I care strongly enough to spend a whole bunch of time arguing the point, only enough to raise it as a concern and see if others agree.) Jeff ___ 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: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
It was decided to allow it for consistency with 0XFF and 0B11 and leave this up to style guides and linters. On Tue, Jul 23, 2013 at 12:04 PM, Jeff Walden jwalden...@mit.edu wrote: var n = 0O755; Is this something anyone wants to read? I certainly don't! Allowing only lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on balance I think that's probably preferable to admitting this monstrosity. :-) (Which isn't to say I care strongly enough to spend a whole bunch of time arguing the point, only enough to raise it as a concern and see if others agree.) Jeff ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
I'm with Jeff. YAGNI, YouWillHateIt, ItWillMakeYourEyesBleedWhenYouLeastExpectIt. Remember homomorphic URL phishing attacks? /be Erik Arvidsson wrote: It was decided to allow it for consistency with 0XFF and 0B11 and leave this up to style guides and linters. On Tue, Jul 23, 2013 at 12:04 PM, Jeff Waldenjwalden...@mit.edu wrote: var n = 0O755; Is this something anyone wants to read? I certainly don't! Allowing only lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on balance I think that's probably preferable to admitting this monstrosity. :-) (Which isn't to say I care strongly enough to spend a whole bunch of time arguing the point, only enough to raise it as a concern and see if others agree.) Jeff ___ 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: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
``` var Oo22 = 60 window.alert(Oo22 - 0o22) // 42 O_o ``` Indeed, you ain't gonna need it for obfuscating your code, there's already more than one way to do it. :-) Since there won't be much code containing words starting with OO, O0, 0O or 00, the risk of eye-bleeding is low. OT0H, it would only be good for facilitating the work of obfuscators (all their numerical constants will start with 0O or 00, and all their variables with OO or O0 followed by digits). —Claude Le 24 juil. 2013 à 02:06, Brendan Eich bren...@mozilla.com a écrit : I'm with Jeff. YAGNI, YouWillHateIt, ItWillMakeYourEyesBleedWhenYouLeastExpectIt. Remember homomorphic URL phishing attacks? /be Erik Arvidsson wrote: It was decided to allow it for consistency with 0XFF and 0B11 and leave this up to style guides and linters. On Tue, Jul 23, 2013 at 12:04 PM, Jeff Waldenjwalden...@mit.edu wrote: var n = 0O755; Is this something anyone wants to read? I certainly don't! Allowing only lowercase 'o' in octal literal syntax is inconsistent with 'x' and 'b', but on balance I think that's probably preferable to admitting this monstrosity. :-) (Which isn't to say I care strongly enough to spend a whole bunch of time arguing the point, only enough to raise it as a concern and see if others agree.) Jeff ___ 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: Is it really a good idea for octal numbers to allow capital-O, e.g. 0O755?
Claude Pache wrote: the risk of eye-bleeding is low. My eye already bled just from this thread! http://cheezburger.com/2253407488 /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
