ptalk > Dear Lazzie

Equality and Identity in Javascript

A reader from Plymouth writes,

So I’m profiling along, and I find an anonymous function that is being called a number of times. It doesn’t cost a lot, but I’m curious why it is anonymous. It’s not really anonymous, because our compiler assigns a debugging name to anonymous functions that you can use to find them in the source. Here’s the anonymous function:

static var _ignoreAttribute = {toString: function () {
      return '_ignoreAttribute'}};
  

_ignoreAttribute is just a unique sentinel object that we use as a way to indicate that an attribute has already been processed, deep in the inner workings of LZX. Someone (probably me) graciously gave it a toString method, so that when you are debugging and trip across it, you will realize that it is not just any old empty object.

But I’m not debugging. I’m profiling. I’m not calling _ignoreAttribute.toString(). It’s nowhere in the source code that I can see. What is going on?

Gentle reader,

Well, here’s a problem:

if (null != this.datapath && dp != LzNode._ignoreAttribute) {
  this.datapath.setXPath(dp);
} else {

Can you spot it? When dp != LzNode._ignoreAttribute runs, dp is normally a string, and read the fine print for how equality is computed in Javascript (from p. 64 of ECMAScript Language Specification Edition 3):

1. If Type(x) is different from Type(y), go to step 14. […]
2. If Type(x) is either String or Number and Type(y) is Object, return the result of the comparison x == ToPrimitive(y).

Well, I won’t bore you with more gory details, but the bottom line is, every time we compare _ignoreAttribute to a String, the runtime has to call its toString method to see if it is “equal”.

The storal of the morey is, when you want to compare for “identity”, use the “strict equals operator” (=== or !==), not the “equals operator”. [For my money, the former should have just been called the “identity” operator, but unfortunately it isn’t quite. There are some odd edge cases that make it not a true identity operator.]

I am a hacker

A reader from Maine asks:

Are your computer skills such that you could be a hacker if you wanted to
be? I’m just curious.

Gentle reader,

I am a hacker.

The popular press has co-opted the label “hacker”, which was originally a compliment of your high degree of computer skills, to mean a person who uses those skills for evil.1

If you are asking “Could I break into someone’s computer”, the answer is “yes”. There is no magic here. I started my computer career working in computer security at MITRE. And, believe it or not, things have not really changed much since those days. If anything, computer security has gone downhill quite a bit. No one has ever succeeded in commercializing the research we did (to build a secure system from the ground up), instead commercial enterprises have all focussed on selling “barn door” solutions, so called because they are attempts to close the barn door, despite the fact that a lot of (Trojan) horses have already been through…

—

[1] http://en.wikipedia.org/wiki/Hacker(computing)#Hackerdefinition_controversy “Hacker (computing) - Wikipedia, the free encyclopedia”

OL 4.3!

We are pleased to announce that OpenLaszlo 4.3 is available now. You can download it from the OpenLaszlo Download page. It is the recommended platform for all application development for the SWF8, SWF9, and DHTML runtimes. OpenLaszlo 4.3 is a major release, with almost 300 bugs fixed since OpenLaszlo 4.2 introduced the SWF9 runtime.

OpenLaszlo 4.3 Released

‘nuff sed.

OpenLaszlo under a Bushel?

A reader from Germany writes:

Laszlo has to sell products and make money, but I think the OpenLaszlo platform has lost in priority with the current management. Not money-wise (how much money they spend on it), but seeing it as a marketing-vehicle for the company. I would love to see more DHTML apps, that would really convince people of the dual-runtime power.

Gentle Reader:

I look at it this way: OpenLaszlo is practically a separate entity. Laszlo is our main sponsor, so we mostly do what they ask. But, we do have other sponsors: G.ho.st directly, others through support contracts. So they also get attention. Community stuff comes last, because that has no $ attached to it. But community leaders can be given commit privileges and see their goals achieved directly.

While OpenLaszlo is a valuable technology base, the company can’t make (as much) money off of it as they can with a proprietary product. Laszlo is doing kind of the same thing as Apple: adding proprietary value to an open-source base. And, we like that, because it means they can “donate” more money to the OpenLaszlo team. :)

Laszlo is a venture-backed company, and venture capitalists are all about making money. They pretty much only see as far as the Webtop licenses. But the management has been made well aware of how the community has made the base they build on much more solid than what they would get with a closed source.

As to DHTML applications, in reality, swf9 is so different from swf8, that is the more convincing port to me! swf8 and DHTML are only different in their UI model, the Javascript is 99% the same. To do swf9, we really had to re-engineer the guts of the whole tag compiler and script compiler, to implement a lot of Javascript 2 (Harmony) and then compile down to Javascript 1 for swf8 and DHTML.

We knew it would be a lot of work, but we knew if we could do it, we would really prove we had a platform-independent language in LZX, and we ended up with a much more robust system in the end.

There is a rule of thumb: 2 ports does not make you platform-independent, it is the 3rd that is the test!

In the end, we were very pleased that we were able to keep nearly all the dynamicity of LZX and target a strongly-typed, much more static platform. The strong-typing and ‘true’ classes of Javascript 2 have given significant performance gains (some claim a speed-up of 5-6 times), but the OpenLaszlo compiler has been able to shield the LZX developer from most of the requirements of declaring types and overrides in their LZX code and has been able to keep dynamic features like <state>s and constraints.

Let me conclude by saying, overall you are right. OpenLaszlo needs more publicity, whether for Laszlo as a company, or just for it’s own growth. Let’s hope this little post can help it along the way…

The difference between `.` and `[` in Javascript

We recently had a bug report that the debugger started issuing a warning in code where it had not before:

 WARNING: reference to undefined property 'length'

The initial fix proposed was to simply change:

 foo.length

to:

 foo.['length']

Advice for the OpenLaszlo optimizer

Since the OpenLaszlo compiler does not do common-subexpression elimination, when you are trying to optimize things, pretend you are writing in 1985 C. Instead of:

if (d.c[d.f]) d.c[d.f]( sd )

say:

var f = d.c[d.f];
if (f) f(sd);

Even better, when you find yourself having to write a null check, ask yourself if it would be cleaner, simpler, and more efficient to have the variable you are referencing not be nullable. For instance, if a variable is an array, consider using an empty array for its initial value, rather than null. This is a time/space trade-off: if there are many operations on the array and the variable is almost always not null, it will be more efficient to use an empty array; if there are few operations and the variable is usually null, then not allocating the empty array is the better choice.

(In Javascript 2, you will have the option of declaring a variable to be of a particular type, and you will have the option of declaring whether or not that variable can also be null. If you declare it not to be nullable, then the compiler will give you a compile-time warning if it cannot prove that the variable is never null, and it will insert the appropriate runtime check for you.

// This can be null, you have to check before using
var uplinkArray: Array;

// This cannot be null, you have to give a valid initial value
var uplinkArray: Array! = new Array();

Even though we don’t yet support the type declarations, we can follow the pattern and be ready…)

Undefined redux

A reader from Maynard asks:

My understanding is that in js, if a variable is declared var foo, and then it is read without an explicit initializer or setter being called, the variable still has a value of undefined and an error is signaled. If that is so in all js dialects then I don’t see any reason why adding variable declarations [to a class declaration] should ever cause problems. I don’t see how it could affect inheritance, for example. Am I missing something?

Order in the code

A reader from San Mateo writes:

I expected this to print the words of my phrase in order. It did not. What gives?

lzx> words = "The quick brown fox".split(" ") 
«Array(4)#55| [The, quick, brown, fox]» 
lzx> for (var w in words) Debug.write(words[w]); 
fox 
brown 
quick 
The

Gentle reader,

for in iterates over the ‘keys’ of an object. An array is just an object that happens to have (mostly) numbers as keys (and auto-maintains a length property that is one larger than the largest numeric key).

An object is just a hash table, and there is no implicit order of elements of a hash table (Java has LinkedHashMap which preserves entry order for iteration, and TreeMap which sorts entry order for iteration, but Javascript is a simpler language).

If you want to iterate over an array’s entries in order, use for (var i = 0; i < array.length; i++).

lzx> for (w = 0; w < words.length; w++) Debug.write(words[w]); 
The 
quick 
brown 
fox

If you want to iterate over an object’s keys in a particular order, you have to pull the keys out into an array, sort that array, and then iterate over that array:

var keys = new Array();
foreach (var k in array) { keys.push(k); }
keys.sort(function (a, b) {
  return (a > b) - (a < b);
});
for (var i = 0; i < keys.length; i++) {
  Debug.format("%s -> %s\n", keys[i], array[keys[i]]);
}

The fact that any particular runtime iterates over object keys in any particular order reveals an implementation detail of their hashes, but if you write your code to depend on that you are setting yourself up for a fall. Most Javascript runtimes just happen to use particularly trivial hash implementations that give you the illusion the keys are iterated in order.

See also the yellow box caution here.