Javascript ‘==’ operator and indexOf failure

The other day my collegue, Steve Skrla, was having an infinite recursion issue caused by my javascript clone function. We discovered that the for some reason it was equating a string value with an array value. After a little more digging Steve found the culprit. Simply put, Javascript’s == operator is broken.

I did a little more digging and discovered exactly what Javascript is doing. It turns out that when comparing anything to a string, Javascript first runs a toString on the other item being compared.

Continue reading

ExtJS – Update to ComboBox Replacement

Some people were asking for some additions to my ExtJS ComboBox replacement, so here is a quick little update.

This version adds in some minor fixes and a new feature. The ComboBox will now properly consume an existing combo. If you do not have selected=”true” on one of the options then this combo will clear the value of the ExtJS Combo box so that no value is selected.

I need to add some more documentation and testing and then I will make it an official UX component. I am also working on some examples of Ext’s combo vs this combo to show you why it is better.

Continue reading

ExtJS / Javascript – Deep Copy

We often need to do deep copies of Javascript objects so that we can modify the copy without it affecting the original. I have created the following clone function that does this quickly and easily; however, it does have limitations. If you clone an instance of, lets say, an Ext.Panel, Javascript’s instanceof function will fail to recognize it as an instance of Ext.Panel. From what I can gather, this is because the Javascript engine has some kind of internal reference to an object’s constructor and instanceof doesn’t actually look at the constructor we are able to modify… lets look at an example so it is more clear:

Continue reading

Javascript2 Generics – The dot, explained

There was a link on Ajaxian a while ago about Javascript2 and Generics. Everyone was either up in arms that Javascript2 was going to implement generics in the first place or that the syntax was weird with the dot in there. I am of the second camp. I did some research and discovered a little more information on why this decision was made. Take a look at the javascript generics syntax discussion:

  • Angle brackets are hard to parse because they are not normally used as brackets and because ECMAScript does not clearly delineate “type” context expressions from “other” expressions.
    • For annotations we can perhaps fix the parsing problem by introducing syntactic constraints on type expressions.
    • With parameterized function types, we will need unbounded lookahead: one can’t disambiguate until one sees the closing angle bracket. This complicates the parser substantially.

So, the reason this syntax was chosen is to ease parser developer’s lives.  The primary reason being that the parser cannot tell whether a < is the start of a parametrized definition or if it is just a less-than-sign.  This is why they tentatively decided on prefixing the dot on there.  I suppose I understand this, especially with a type un-safe language like Javascript.  I am still hoping they choose to make the parser developer’s lives more difficult so my life can be easier :-).

If you read on in the discussion someone states that they might choose to drop the dot later.  (fingers crossed)  Honestly though, if I get a decent Javascript IDE out of these language changes then I am fine with the dot.