Quote:
Originally Posted by felgall
The current (X)HTML standard uses a strict doctype as pages written for HTML4/XHTML1.0 should not be written using HTML3.2 tags. The current JavaScript standard can use the "use strict" directive because pages written for EXCMAScript 5 should not be ECMAScript 3 commands that are no longer a part of JavaScript but which are now supported simply to avoid breaking all the antiquated scripts that still use them. The reason callee is included in ECMAScript 5 & 6 is as a deprecated command for backwards support for older scripts that still use it. Having seen that most of the web is still written using HTML 3.2 tags those looking after the JavaScript standards don't expect all of the now obsolete JavaScript commands to disappear all that quickly either - especially when some people appear to be assuming that the new version of JavaScript is a subset when in fact it still contains unnecessary commands that are still valid but which shouldn't be used.
|
heh; my point was actually what we should be using HTML5 now...
many of the "deprecated" stuff in xhtml trans that was removed in xhtml strict is back in html5, by popular demand. that's my point.
i remember back in 2008 people were mocking html5 saying stuff like "html5, wow that's great if i don't mind waiting until 2013 to write my site"... Well even those slow adopters who follow the crowd instead of leading it have switched over, since it is five years later and compliance is about 9/10 clients. It's probably still not even an "According to Hoyle" standard, but that's not going to stop anyone from using it this afternoon.
i believe you are making a valid de jure philosophical argument, whereas my assumptions are more de facto and pragmatic...
"still valid but which shouldn't be used" ? wtf? why not? that doesn't make a whole lot of sense does it? anyone who's been in web development for a while knows the discrepancy between card-shuffling on a standards committee and what actually works in the here and now. That's a good thing: it gave us innerHTML, ajax, localStorage, JSON, [].map(), and many other useful now-standardized features.
i'll go so far as to agree that arguments.callee is deprecated, but that doesn't mean it's not present and operational. Furthermore, the soonest opportunity to turn it off will be with the release and uptake of ECMA7. I think it's fair to say that's at least five years away. Meanwhile this works right now, in all semi-recent and future browsers. Both "use strict" and full JS work in all browsers, they are both there, and nothing is on the verge of disappearing.
Quote:
Originally Posted by felgall
Anyway, you still haven't responded to the question I asked in my first post on this thread. I agree that what you are trying to do here is a good idea. Do you have any thoughts on how to implement it without using commands that were removed from JavaScript back in 2011?
|
that fallacious question impossible to answer.
It's like asking "does the king of France have a beard?"
the commands were
deprecated, not
removed; BIG difference!
so the question is more accurately:
"if I opt-out of Javascript's full available feature set, does this new feature work as shown?"
The answer is no, of course not; it's among the features you chose to opt-out of. you can't eat the cake without eating the calories. Meanwhile this works forward and backwards for 5 years, not bad in this fast-moving enviroment; nothing's perfect or lasts forever.
argument's "non arrayidness" is considered a bug. this code fixes that bug right now in the real world. To me, that's more valuable than pedantic conformance to a sub-section of some pdf somewhere... If they wouldn't have screwed the arguments up in the first place, we would need to use one bug to fix another.
once ecma7 does come out, we'll have (hopefully) been able to use code like this for several years:
Code:
function sum(...args){
return args.reduce( function(a,b){a+b} );
}
note the rest params and tail returns...
meanwhile, "use strict" workarounds:
- use wrappers to turn arguments into an array
- remove the global "use strict" directive (as almost everyone recommends)
- load the script from an external script tag in a file that doesn't have "use strict".
Those are all easy enough fixes.
there are other shim-like workarounds, but they are WAY nastier than arr(arguments) and involve eval, dataURL-based scripts, throw, and a host of other nastiness.