A re-introduction to JavaScript
developer.mozilla.org
developer.mozilla.org
Welcome to tons of JS Unicode String libraries to work around this problem :-(
You need a library for that regardless of whether the underlying representation is UTF-16 or UTF-32....
Calling the respective methods to get a strings length for example will always return the length in characters. There is no way to get to the byte length without explicitly naming an encoding you'd like to get the byte length for.
Older languages, like PHP or JS, Python 2 and Ruby 1.8 leak their internal implementations. The methods to retrieve a string length would return the amount of bytes the internal representation of the string requires. If you need the length in characters, you need to call different methods - sometimes even from external libraries.
Not true until Python 3's "flexible strings" implementation. Unless you're using "wide" builds (which use UTF-32 internally), which are already available in Python 2 and are not the default representation.
That's a matter of Linux distributions packaging (again, by default, without any specific configuration, Python will set itself up using narrow builds), and if you assume wide builds your code is broken.
Furthermore, pilif asserted a difference between Python 2 and Python 3. There is no such thing prior to the yet-unreleased Python 3.3 as making wide builds the default was explicitly rejected for Python 3, Python 2 and Python 3 behave exactly the same way on that front (again, prior to Python 3.3)
Of course pilif is also wrong in asserting that "The methods to retrieve a string length would return the amount of bytes the internal representation of the string requires.", Python < 3.3 returns the number of code units making up the string (never the number of bytes for the the unicode string types — str/bytes is a different matter as it's not unicode data)
Most languages return the length in _unicode characters_, which is just the number of codepoints.
However, in most cases, the programmer actually wants the number of user-perceived characters, ie _unicode grapheme clusters_.
UTF-32 has to be treated as a variable-length coding in most cases, no different from UTF-16 - otherwise, you'd miscount even characters common in western languages like 'ä' if it happens that the user used the decomposed form.
Even normalization doesn't help with that, as not all grapheme clusters can be composed into a single codepoint.
Perl6 is an example of a language which does the right thing here: Its string type has no length method - you have to be explicit if you want to get the number of bytes, codepoints or grapheme clusters.
To add some confusion back in, the language also provides a method which gets the number of 'characters', where the idea of what a character is can be configured at lexical scope (it defaults to grapheme cluster).
That's actually pretty cool, as it lets the library configure itself for the representation which makes most sense to it: a library which deals in storage or network stuff can configure for codepoints or bytes length, whereas a UI library will use grapheme clusters for bounding box computations & al.
Configuring it lexically also makes sense as it avoid leaking that out (which dynamically scoped configuration would).
length: This word is _banned_. Evil. DO NOT USE!
chars: Same thing as length, just with a new name oO
http://unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries
alert("🐱"); // a cat face
alert("🐱".length); // 2
alert("🐱"[0]); // an unknown character
alert("abc🐱de".indexOf("🐱")) // 3
From what I understand this is not a case of a unicode character with a second character applied as an accent. Although it's possible it may be behaving the same way.
In any case, it's interesting to see the delete key change a character to something else rather than fully delete it.
(UTF-8 is another variable-width encoding where a code point can be anywhere from one to four 8-bit code units, and UTF-32 is a fixed-width encoding where every code point is exactly 32-bit one code unit. Because code points can be accents or modifiers, UTF-32 is still variable-width with respect to characters, because there's no guarantee that a given character is composed of a single code unit.)
Because UTF-16 is a variable-width encoding, and because JavaScript exposes UTF-16 code units (instead of code points or characters), it is possible to delete half of a code point and even end up with an invalid UTF-16 string in some cases (IIRC). As another comment mentions, some languages (e.g. Python 3) expose code points instead, which still isn't the same as characters.
Then again, they're broken like most other "unicode" string types (Java's and C#'s, Python's — default — narrow builds until Python 3.3, Cocoa in some ways, etc...) in that the string "API" produces user-facing "UCS-2 plus surrogates" so it's nothing new under the sun.
$ /usr/bin/python -c'import sys; print sys.maxunicode'
1114111No, on your linux distribution it's setup with a wide build, the default compile option in the upstream package is narrow build on all platforms.
Wisely, the author did link to https://developer.mozilla.org/en/Introduction_to_Object-Orie... to fill in the gaps.
function addHandler() { var el = document.getElementById('el'); el.onclick = function() { this.style.backgroundColor = 'red'; } }
I'm assuming the author believes `this` is evaluated immediately and refers to the `el` variable instance, rather than being evaluated when the function is called.
Any ideas?
From what I remember the closure will keep a reference to el even though it will never use it, which means el won't be garbage collected when removed from the dom, which means the closure won't be removed from the onclick to free up el. Hence a circular reference. IE6's javascript garbage collector couldn't detect that.
The article is old. Here's an article from MS in 2005 describing the problem in more detail:
http://msdn.microsoft.com/en-us/library/Bb250448
Apologies if you understood that and were just saying the code is wrong, but it looks right to me. Not that I can be bothered to fire up IE6 to test it out.
EDIT: Some more detail about the definitely historical leak from SO, it also turns out it was only partially fixed in IE7:
http://stackoverflow.com/questions/1999840/javascript-circul...
Die, Explorer, die! :-)
(function () {
var foo = "bar";
return function(_var) {
return eval(_var);
}
})()('foo');If you change the inner function call parameter 'foo' to ('alert("hi")') you'll see the reference to foo='bar' is still maintained in the inner function. So there is no -direct- reference to foo in the inner function, but there isn't even an -indirect- reference being made in the call to eval. The reference to foo is being maintained purely because eval "might" require it. Or so it appears.
If the return eval(_var) statement is replaced with alert('blah') we're back to foo being undefined in the inner function. So I've definitely got my finger pointed at eval on this one.
It looks like my previous example was affected by eval.
The following reports foo's value as undefined while breaking for the debugger statement in Firefox and Chrome:
(function () {
var foo = "bar";
return function() {
debugger;
};
})()();
(function () {
var foo = "bar";
return function(_var) {
debugger;
return eval(_var);
};
})()('foo');> The fourth edition was abandoned, due to political differences concerning language complexity. Many parts of the fourth edition formed a basis of the new ECMAScript edition 5, published in December of 2009.
EDIT: If you scroll to the bottom right it says: "Page last modified 21:08, 5 Jan 2012 by Janet Swisher"
I learned something new.