There are some methods using reserved word delete, such as
Map.prototype.delete, Set.prototype.delete... Though it is allowed since
ES5, I think we'd better avoid it because it cause es6 shim solution fail
on legacy browsers such as IE8.
--
hax
___
Le 17/12/2013 10:19, Shijun He a écrit :
There are some methods using reserved word delete, such as
Map.prototype.delete, Set.prototype.delete... Though it is allowed
since ES5, I think we'd better avoid it because it cause es6 shim
solution fail on legacy browsers such as IE8.
Note that there
On Tue, Dec 17, 2013 at 4:19 AM, Shijun He hax@gmail.com wrote:
There are some methods using reserved word delete, such as
Map.prototype.delete, Set.prototype.delete... Though it is allowed since
ES5, I think we'd better avoid it because it cause es6 shim solution fail
on legacy browsers
On Mon, Dec 16, 2013 at 6:06 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
last thought would be an answer to th epossible question:
do we need to support mozMatchSelector forever ?
NO
since matches() will do once it works as standards say
No, that's not how it works. You
sorry what ?
https://github.com/WebReflection/es6-collections#es6-harmony-collections-fast-polyfill
https://code.google.com/p/es-lab/source/browse/trunk/src/ses/WeakMap.js
https://github.com/Benvie/ES6-Harmony-Collections-Shim
https://github.com/paulmillr/es6-shim
The real-world out there always tries to address the potential standard and
use these prefixed methods as fallbacks, not vice versa.
It would be very unwise to rely prefixed methods only in production and I
am not sure who does it but yes, the dropping might be gradual notifying
in console that
not shold but **does** work ;-)
Although I agree that specific thing is very inconvenient in some case and
minifiers knows this too.
As example, google closure compiler fails with this script in two ways
```javascript
var wm = new WeakMap;
wm.delete(Object);
```
Simple minification does the
You can't run any ES6 script in a browser that don't support ES6, because they will throw syntax error at the first yield (unless you're using compiler like traceur, but it won't have a problem with getting .delete work either). If you use shims, that's fine, but you're not writing ES6, you're
ES6 scripts will not work in IE8. Period. What's the point of making it work with a bit more ES6 scripts since all of them will never be supported anyway? I would only welcome if that badly written or outdated software gets exposed this way. 17.12.2013, 22:59, "Andrea Giammarchi"
IE6 ? ... I don't understand your argument. We are talking about IE8 and
polyfills that work already plus this does not solve the main problem which
is about tools not always compatible with ES6 and/or future proof and shim
aware.
If tools were OK you wuld just write wm.delete(obj); and the tool
On Tue, Dec 17, 2013 at 12:43 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
The real-world out there always tries to address the potential standard and
use these prefixed methods as fallbacks, not vice versa.
That's not true.
almost nobody uses anymore pure CSS and prefixes there
Well, you said that it works in IE8, and I don't care enough to test it, so said about IE6 because it is the same legacy kind of thing. Doesn't matter. Legacy and broken tools is not a valid reason to avoid perfectly good method name, especially considering the fact that it is a valid ES5 syntax
That's why my first hint was .del() as it is in Python and makes sense
since ever and it could have made perfect sense in JS too, also as alias
for .delete() while transitioning from ES3 legacy, ES5 quirk engines, and
ES.next
That being said, I was simply warning that tools might break so this is
Are you able to provide Pros of the non prefixed decision or that's all you
have to say about it?
Not even a link?
How useful has your answer been for anyone?
Which library uses window.webkitRequestAnimationFrame before
window.requestAnimationFrame and why nobody filed a bug until now?
Plus I
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
Object.assign(target, source1, source2, ...) // equivalent to
`Object.assign(Object.assign(Object.assign(target, source1), source2), ...)`
My use case: I have
[target, s1, s2, s3].reduce(function(p, c){
return Object.assign(p, c);
});
On Tue, Dec 17, 2013 at 5:06 PM, Claude Pache claude.pa...@gmail.comwrote:
Hello,
Tonight, when playing with ES6’s new functions, I was wishing that
`Object.assign` could accept several `source` objects:
P.S. actually, that is the equivalent of `[target, s1, s2,
s3].reduce(Object.assign);` but I was not sure it accept extra arguments too
On Tue, Dec 17, 2013 at 5:16 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
[target, s1, s2, s3].reduce(function(p, c){
return Object.assign(p,
FWIW I don't see any other usage for extra arguments neither
On Tue, Dec 17, 2013 at 5:17 PM, Brendan Eich bren...@mozilla.com wrote:
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding
this. But
Interestingly, if multiple arguments are not added now, they may never be
possible, since there will be so much `[a, b, c].reduce(Object.assign)` code in
the wild that implicitly passes an index as the third parameter and the whole
array as the fourth parameter.
-Original Message-
Your insight about Andreas's reduce example seals the deal for me.
/be
Domenic Denicola mailto:dome...@domenicdenicola.com
December 17, 2013 5:20 PM
Interestingly, if multiple arguments are not added now, they may never
be possible, since there will be so much `[a, b,
true ... as true is for anything that will ever be passed to reduce that
accept just 2 arguments. Handy in a way, blocking progress in others.
`Object.assing(target, ...[multSources]);`
wins to me
On Tue, Dec 17, 2013 at 5:20 PM, Domenic Denicola
dome...@domenicdenicola.com wrote:
the alternative is that the second argument expects an array of 1 to n
source objects. This works with reduce and leaves way clear for future 3rd
argument (eg deep copy boolean)
On Tue, Dec 17, 2013 at 5:24 PM, Andrea Giammarchi
andrea.giammar...@gmail.com wrote:
true ... as true is for
Angus Croll wrote:
the alternative is that the second argument expects an array of 1 to n
source objects. This works with reduce and leaves way clear for future
3rd argument (eg deep copy boolean)
Mandatory array-of-parameters is an anti-pattern, given spread. Even if
the allocation costs
Has the specification licensing issue been addressed? What is the result?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Tue, Dec 17, 2013 at 8:17 PM, Brendan Eich bren...@mozilla.com wrote:
It's now or never. I agree multiple sources are useful enough to do now; I
don't see a different third parameter that would be precluded by deciding
this. But others may disagree.
A third Properties argument that
You may not care about IE8, but many developers in the world MUST care
about it.
What I suggest is to help ES6 be faster to adopt, you know most team in
companies are conservative to edge tech, that's why we need es5-shim or
es6-shim projects.
It's too bad to write map['delete'], and you can't
ADVANCED mode requires property definitions for external properties. There
aren't ES6 definitions in the default externs for Map or other new features.
On Dec 17, 2013 10:59 AM, Andrea Giammarchi andrea.giammar...@gmail.com
wrote:
not shold but **does** work ;-)
Although I agree that specific
such name just trouble the developers who want to migrate to ES6 step by step How can you migrate to ES6 if you didn't even migrate to ES5 first? 18.12.2013, 07:17, "Shijun He" hax@gmail.com:You may not care about IE8, but many developers in the world MUST care about it.What I suggest is to
On Wed, Dec 18, 2013 at 11:30 AM, Rick Waldron waldron.r...@gmail.comwrote:
Right, and map[delete](key) works fine. The future of the language
itself should not be impaired by a browser that has an expiration date.
No, it does NOT work. Because you can't ask all module/library authors
write
On Wed, Dec 18, 2013 at 11:28 AM, Alex Kocharin a...@kocharin.ru wrote:
How can you migrate to ES6 if you didn't even migrate to ES5 first?
Even IE5 (pre-ES3) can use string.prototype.repeat with simple shim.
And with es6 shim, Map/Set SHOULD works on IE5, and all modules depend on
Map/Set
Rick I tend to aree with you if not that the second argument of
Object.create has basically reached zero libraries and popularity out there
due un-shimmable and boring to write common/usual properties.
In this very specific case it would be inconsistent with the previous
argument too since that
On Tue, Dec 17, 2013 at 10:45 PM, Shijun He hax@gmail.com wrote:
On Wed, Dec 18, 2013 at 11:30 AM, Rick Waldron waldron.r...@gmail.comwrote:
Right, and map[delete](key) works fine. The future of the language
itself should not be impaired by a browser that has an expiration date.
On Tue, Dec 17, 2013 at 11:02 PM, Shijun He hax@gmail.com wrote:
On Wed, Dec 18, 2013 at 11:28 AM, Alex Kocharin a...@kocharin.ru wrote:
How can you migrate to ES6 if you didn't even migrate to ES5 first?
Even IE5 (pre-ES3) can use string.prototype.repeat with simple shim.
And
33 matches
Mail list logo
