You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(I feel weird leaving this here, because it's not like es5-shim had anything to do with it. This issue tracker looks like the graveyard for bugs in abandoned browsers.)
new String('foo') in IE7/IE8 returns an object:
typeofnewString('foo')// object
Likewise, 'foo' is a string:
typeof'foo'// string
Both of these values have a constructor of String. When called with Object.prototype.toString.call(value), both return [object String].
But the former is actually some sort of array-like object having a length of 3; the values of which are all undefined ([undefined, undefined, undefined]). This is strange in that the properties are enumerable, but have no value. The object inherits String.prototype otherwise.
AFAICT, it's impossible to actually reference the characters by index (new String('foo')[0]); Firebug Lite fails to do so. This is problematic, because one expects to be able to use for .. in to iterate over object keys and access values.
Possible solutions:
shim the entire String constructor (feasible?)
other shimmed methods which perform iteration may want/need to detect this type (an object with constructor String) and coerce into an Array first
This is how JS works - you're never supposed to use new String. Separately, in IE 6-8, it's utterly impossible to reference string characters with bracket access - you're supposed to use .charAt(i).
You should also never use for..in to iterate over objects - use Object.keys and iterate over the resulting array.
Please don't be patronizing. This issue has nothing to do with "should" or "shouldn't".
The point of this project is to help developers avoid writing their own special cases and feature detection. Bringing String up to ES5 standards--as far as it can--would further that goal. So, I don't understand why this was closed.
I apologize; I wasn't intending to be patronizing.
I closed it because bracket access of strings in IE 6-8 is impossible - the JS engine has bugs and doesn't allow it.
Replacing the String constructor wouldn't allow it on primitive strings - only on String objects. Since charAt exists, and is a best practice in all code, there's not really much benefit of doing so.
"should" definitely matters, since best practices evolved out of web realities. The mocha issue is because it's incorrectly using for..in to iterate - if it used Object.keys or https://npmjs.com/object.keys then it would work fine.
If there's something actionable, I'll be happy to reopen this issue. I'm just not sure what the es5-shim can possibly do here.
(I feel weird leaving this here, because it's not like es5-shim had anything to do with it. This issue tracker looks like the graveyard for bugs in abandoned browsers.)
new String('foo')
in IE7/IE8 returns an object:Likewise,
'foo'
is a string:Both of these values have a constructor of
String
. When called withObject.prototype.toString.call(value)
, both return[object String]
.But the former is actually some sort of array-like object having a length of 3; the values of which are all
undefined
([undefined, undefined, undefined]
). This is strange in that the properties are enumerable, but have no value. The object inheritsString.prototype
otherwise.AFAICT, it's impossible to actually reference the characters by index (
new String('foo')[0]
); Firebug Lite fails to do so. This is problematic, because one expects to be able to usefor .. in
to iterate over object keys and access values.Possible solutions:
String
constructor (feasible?)object
with constructorString
) and coerce into anArray
firstOriginal issue: mochajs/mocha#2496 by way of JetBrains' WEB-23383.
The text was updated successfully, but these errors were encountered: