Function.prototype.apply = function(thisArg, argArray) {
    if (typeof this != “function”) {
        throw new Error(”apply called on incompatible ” +
                    “object (not a function)”);
    }
    if (argArray != null && !(argArray instanceof Array)
        && typeof argArray.callee != “function”) {
	throw new Error(”The 2nd argument to apply must ” +
                    “be an array or arguments object”);
    }

    thisArg = (thisArg == null) ? window : Object(thisArg);
    thisArg.__applyTemp__ = this;

    // youngpup’s hack
    var parameters = [],
        length = (argArray || “”).length >>> 0;
    for (var i = 0; i < length; i++) {
	parameters[i] = “argArray[” + i + “]”;
    };
    var functionCall =
            “thisArg.__applyTemp__(” + parameters + “)”;

    try {
	return eval(functionCall)
    } finally {
	try {
            delete thisArg.__applyTemp__
        } catch (e) {
            /* ignore */
        }
    }
}

Function.prototype.call = function(thisArg) {
    return this.apply(thisArg,
            Array.prototype.slice.apply(arguments, [1]));
}

Download: apply-call.js

Validating apply’s context and parameters

The ECMAScript specification says that apply may only be called on objects with a [[Call]] property (i.e. functions), and a TypeError should be thrown if an attempt is made to call it on non-function objects. The typeof operator allows us to identify functions easily: typeof object evaluates to "function" if and only if the object has a [[Call]] property.

The second parameter to apply is optional, but if it’s supplied it must be either an array or an arguments object - if not, a TypeError should be thrown. The expression argArray != null is deceptively simple, but exploits an interesting JavaScript fact: object == null evaluates to true if-and-only-if object is null or undefined (so object != null evaluates to true for any value except null or undefined.)

Checking whether an object is an instance of an array is simply a matter of using the instanceof operator with the Array constructor Array (i.e. object instanceof Array.) To check whether something is an arguments object is a little more complicated as the ECMAScript specification does not define an Arguments class or function. We resort to a capability test: we check whether the object has a callee property that’s a function (typeof object.callee == "function".) I think this is a better test than checking for a numeric length property, as both String and NodeList have length properties defined, but neither of them are should be accepted when passed as the second argument to apply.

Getting an appropriate object to use as this

If thisArg is null or undefined, the global-scope must be used as this. Since I’m writing this version of apply for use in a browser: the global-scope is the window object.

JavaScript’s typeof operator allows you to differentiate several types of primitive value (booleans, numbers and strings) To turn primitive values into objects (as required by the specification of apply) we pass them through the Object function. From this point on, you should use instanceof instead of typeof to differentiate different types of object.

Using functions as methods

The purpose of apply is to be able to assign a specific object as this for the duration of a function call. Without native browser-support, the only way to achieve this is to assign the function as a property of the object (thereby making the function a ‘method’ of the object.) Ideally we would generate and check for a non-existent property-name - but this cannot be achieved with 100% reliability on our main target browser (Internet Explorer 5) as there is no way of checking for the existence of a property (the specification defines Object.prototype.hasOwnProperty for this purpose; IE5 doesn’t support it, and it cannot be implemented reliably.) Accepting the futility of the situation, we go with a ‘good enough’ implementation and hope that __applyTemp__ isn’t being used for any other purpose.

Establishing how many parameters to pass

We’ve established that argArray is either null, undefined, an array or an arguments object, we now need to establish how many parameters need passing to the function call. The rather obtuse expression (argArray || "").length >>> 0) is dense code to meet the specification: no arguments (0) are passed if argArray is null or undefined, otherwise the length property is cast to an unsigned 32-bit integer, and the result is the number of parameters that will be passed (it’s extremely unlikely that the result will be any different to using the length property as-is; but since it’s trivial to do things properly, we do so.) A more simplistic and readable version of the code would read: (argArray == null) ? 0 : argArray.length

Calling a function with an arbitrary number of parameters

If you google for implementations of apply you’ll inevitably come across code derived from youngpup’s version. I don’t know if he created the hack, but it’s the inspiration for my version, so credit where credit’s due. The purpose of the hack is to pass a variable number of parameters to a function, without having to consider 1, 2, 3, 4 arguments (etc.) separately. The hack works by building a function-call as a string, then passing the string to eval. For example, to pass two parameters, this would be passed to eval: "thisArg.__applyTemp__(argArray[0], argArray[1])"

Error handling and cleaning-up

Earlier on, we attached the function as a method of the object. To ensure this is a temporary attachment, we have to remove the method once the function call has completed (using delete). We have to be careful though, as the function call may cause an error to be thrown, and we don’t want to swallow or ignore this error. Fortunately, we can use the try/finally construct to run some clean-up code after the function call, regardless of whether the function-call ends in an exception or not.

Ideally, cleaning-up would simply be a matter of writing delete object.property; but in the world of Internet Explorer nothing is that simple. Errors can be thrown when you try to delete properties on host objects (a host object is an object supplied by the browser and accessible through JavaScript, but not defined in the ECMAScript specification. e.g. ActiveXObject.) As we don’t imagine anyone will be interested in errors generated during clean-up, we wrap a simple try/catch around the clean-up code to swallow any errors generated here.

Function.prototype.call

It’s trivial to implement call in terms of apply. The first parameter to call becomes the first parameter to apply. The rest of the parameters are passed by applying Array’s slice method to the arguments object. This demonstrates our first useful application of apply: converting arguments objects to standard arrays.

Conclusion

To implement apply we’ve had to understand typeof, functions, methods, this, null, the loose equality operator, global-scope, object properties, try/catch/finally, the arguments object, eval, primitive values and errors. This is a lot of ground to cover for such a short function, and I can’t think of any other function that teaches you so much while writing it.

Server-side validation

It’s a golden-rule of web-development that you never depend on client-side validation. Users can turn JavaScript off, and hackers can send any data they like at your servers. So, the first thing you have to decide is what data is acceptable to your server. For numbers on the server, are you planning on storing them in a database or performing calculations with them? In either case, what format do the numbers need to be in: integers? decimals? Are you going to manually trim white-space from the number, are you going to allow negative numbers?

(it’s tempting to make the server-side validation anally-retentive, not accepting anything except a strict sequence of decimal numbers. I’d suggest that you at least accept (and remove) white-space around submitted numeric values. This will avoid frustrating JavaScript-disabled users in the case where a form-field has some trailing white-space in it - impossible to see, and annoying to find and remove after receiving an “invalid input” error.)

Client-side validation

Once you’ve decided on and coded-up your server-side validation, it’s time to think about client-side validation. Remember, the point of client-side validation is to avoid unnecessary round-trips to the server. If you can determine that user-input on the client isn’t going to be acceptable to the server, don’t even bother sending it; instead, display informative and instructive messages to the user indicating which input you don’t like, why, and what type of input you want from them.

We need an example to work with. I’m feeling unimaginative, so I’m going to use the stock order-form example. Let’s suppose we have a quantity field that (for arbitrary business reasons) we will only accept with an integer from 0 - 100. One naïve approach to validation may be:

var quantity = document.orderForm.quantity.value;
if (quantity < 0 || quantity > 100) {
  // inform user of invalid input
}

Remember, form-field values are always strings, so the code above is relying on automatic type-conversion from strings to numbers using the < and > operators. Unfortunately, if the user doesn’t input anything (quantity === ""), this would be treated exactly the same as if they’d entered 0; and the quantity would pass our input validation.

I just mentioned that the validation would pass for an empty-string; in fact, validation would pass for any input consisting solely of white-space. That’s due to the JavaScript behaviour: "\s*" < 0 is false and "\s*" == 0 is true (where I’ve used \s* to mean ‘optional white-space’.)

Considering parseInt

So, we don’t want white-space to be treated as 0. Fortunately (for now), parseInt (and parseFloat) will return NaN for white-space input. We could try to improve our code like this:

var quantity = parseInt(document.orderForm.quantity.value);
if (isNaN(quantity) || quantity < 0 || quantity > 100) {
  // inform user of invalid input
} else {
  // assume everything's hunky-dory?
}

But, oh dear lord, what a can-of-worms we’ve just opened: parseInt accepts numbers in octal and hexadecimal as well as base-10, and it’s unlikely that we want to send octal or hexadecimal numbers to our server. The sensible thing to do would seem to be to specify that we want to parse base-10 numbers using parseInt(quantity, 10).

This just makes things worse. Where we would have had parseInt("0xFF") returning 255 (and failing validation), we now have parseInt("0xFF", 10) returning 0 which passes our validation. In other words, our client-side code has passed and we’re going to send the server “0xFF” as the quantity. Hopefully your server-side code would validate this and return an error, but it feels like a waste of a round-trip.

There are also problems with floating-point numbers and scientific notation. i.e. parseInt(”2.34″, 10) returns 2 as does parseInt(”2e04″, 10), but either of these inputs could cause problems on the server (”2e04″ is scientific notation for 20000, but parseInt(x, 10) stops parsing as soon as it reads a non-digit character.)

And then there’s the just-plain-strange input: parseInt("3 bikinis", 10) returns 3. What are you going to do with "3 bikinis" on the server? It’s crazy-talk.

Clearly, parseInt is not enough on it’s own.

Regular Expressions

We’re talking about a quantity field, where we want a non-negative integer. A simple-regular expression to check for a sequence of decimal digits is: /\d+/. That still doesn’t help us avoid any trailing characters, so we need to pin it down using the ^ and $ markers. Remembering that the user can’t see white-space, we’ll show some tolerance by allowing leading and trailing white-space round the character (usually, you’d trim the field before validating, but I’m just adding some optional white-space to the regular-expression for now.)

var quantity = document.orderForm.quantity.value;
if (!/^\s*\d+\s*$/.test(quantity) || quantity < 0 || quantity > 100) {
  // inform user of invalid input
} else {
  // do something with quantity?
}

We’re pretty happy that quantity has been entered in the right format, and we’ve used some implicit JavaScript type-conversion to check it’s in the right range (0 - 100.) But surely if we want to do some calculations on it, then we’re going to have to use parseInt or some other method of converting strings to numbers?

Unary + for type-conversion

Forget parseInt. If you know that a variable only contains digits (optionally wrapped in white-space) you can convert it to a number using a single +. Let’s assume we have a couple of hidden fields: unitPrice and shipping. We can assume these hidden fields contain numbers, and we know that the multiplication operator ‘*‘ will do automatic string-to-number conversion for us. But the binary ‘+‘ operator doesn’t (i.e. 4 + "5" equals "45" not 9.) Here’s unary + in action:

var form = document.orderForm;
var quantity = form.quantity.value;
…validation omitted…
var subtotal = form.unitPrice.value * quantity;
var total = subtotal + +form.shipping.value;

I need to be explicit about octal numbers. Although parseInt will (by default) parse octal, hexadecimal and base-10; when it comes to operators, octal is ignored. In other words, "0xff" == 255 is true, but "010" == 8 is false. Similarly +"0xff" is 255 but +"010" is 10.

Unary + has a lot going for it, and if you’re using prototype this should appeal:

var total = ($F('unitPrice') * $F('quantity')) + +$F('shipping');

(though I’ll never understand why they chose to use $F instead of $V. ‘F’ for field, ‘V’ for value, surely? But I digress)

Summary

I set-out to briefly demonstrate how nice and compact unary + is, but managed to get side-tracked once again. The original summary would have been “+ rocks! parseInt sucks”, but instead, we’ve got:

• Beware of white-space
• Know your number formats
• Unary +
• Use regular-expressions to check user-input matches a required format
• Show some lenience

Coming Soon…

The next two articles are very likely to touch on getComputedStyle and CSS’s !important modifier. The first should be quite short (but I tend to waffle, so it’ll probably end up long), and I need to work on some examples or illustrations for the second one. After that, I’m not sure. I’ve got some ridiculous code for creating PNGs in JavaScript, so I’ll probably give that an outing at some point.

Thanks for reading.

It’s been seven years since the publication of the official ECMAScript Language Specification, and I think we should expect a little more from our browsers. In this article, I’ve documented the current problems, and I show how to write library implementations conforming precisely to the language spec’.

JavaScript Implementation

Here are my functions (the >>> operator is explained later in the article):

Array.prototype.push = function() {
    var n = this.length >>> 0;
    for (var i = 0; i < arguments.length; i++) {
	this[n] = arguments[i];
	n = n + 1 >>> 0;
    }
    this.length = n;
    return n;
};

Array.prototype.pop = function() {
    var n = this.length >>> 0, value;
    if (n) {
	value = this[--n];
	delete this[n];
    }
    this.length = n;
    return value;
};

Download: push-pop.js

Testing

Always up for a challenge, I’ve tried to produce a bug-free implementation that conforms to the specification. You can see how it fares on my push and pop test page (fixed link). The test page allows you to compare several library implementations to the browser’s built-in implementation, and mine. There are about thirty tests in all, and you should find that even the browser’s implementations fail a couple of tests (some fail substantially more.)

So, why the high failure rate? Simple: most browsers haven’t implemented arrays correctly; their understanding of an array index and length is wrong. From the specification (section 15.4):

A property name P (in the form of a string value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 2³²−1. Every Array object has a length property whose value is always a non-negative integer less than 2³². The value of the length property is numerically greater than the name of every property whose name is an array index; whenever a property of an Array object is created or changed, other properties are adjusted as necessary to maintain this invariant. Specifically, whenever a property is added whose name is an array index, the length property is changed, if necessary, to be one more than the numeric value of that array index; and whenever the length property is changed, every property whose name is an array index whose value is not smaller than the new length is automatically deleted. This constraint applies only to properties of the Array object itself and is unaffected by length or array index properties that may be inherited from its prototype.

In simplified terms: array indexes are integers in the range [0, 2³²-2], and the array length can take any integer value in the range [0, 2³²-1] (both ranges start at 0, but end at different values.) The length of an array is greater than any set array index; if the length is set explicitly, all array indexes ≥ length are deleted.

Bugs

• setting an array length to a non-integer value, a negative value, or an integer ≥ 2³² should cause an error to be thrown. Firefox is the only browser to get this right - Safari, Opera and Internet Explorer all fail this test (I called this test, unimaginatively, testArrayLength)
• truncating an array doesn’t always cause the right array values to be deleted in Firefox (testArrayTruncation)
• length is updated incorrectly in certain circumstances in Firefox, Safari and Opera (testArrayLengthMagic)

Now we’ve established that every browser has at least one problem with arrays, let’s look at the specification of push:

15.4.4.7 Array.prototype.push ( [ item1 [ , item2 [ , … ] ] ] )
The arguments are appended to the end of the array, in the order in which they appear. The new length of the array is returned as the result of the call.

When the push method is called with zero or more arguments item1, item2, etc., the following steps
are taken:

1. Call the [[Get]] method of this object with argument "length".
2. Let n be the result of calling ToUint32(Result(1)).
3. Get the next argument in the argument list; if there are no more arguments, go to step 7.
4. Call the [[Put]] method of this object with arguments ToString(n) and Result(3).
5. Increase n by 1.
6. Go to step 3.
7. Call the [[Put]] method of this object with arguments “length” and n.
8. Return n.

The length property of the push method is 1.

NOTE
The push function is intentionally generic; it does not require that its this value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method. Whether the push function can be applied successfully to a host object is implementation-dependent.

And the specification for pop:

15.4.4.6 Array.prototype.pop ( )
The last element of the array is removed from the array and returned.

1. Call the [[Get]] method of this object with argument "length".
2. Call ToUint32(Result(1)).
3. If Result(2) is not zero, go to step 6.
4. Call the [[Put]] method of this object with arguments "length" and Result(2).
5. Return undefined.
6. Call ToString(Result(2)-1).
7. Call the [[Get]] method of this object with argument Result(6).
8. Call the [[Delete]] method of this object with argument Result(6).
9. Call the [[Put]] method of this object with arguments "length" and (Result(2)-1).
10. Return Result(7).

NOTE
The pop function is intentionally generic; it does not require that its this value be an Array object. Therefore it can be transferred to other kinds of objects for use as a method. Whether the pop function can be applied successfully to a host object is implementation-dependent.

The notes in both specifications are very important - they mean that each method must be portable, able to work in isolation - no dependence on other Array methods or properties. Implementation should not rely on side-effects of manipulating a length property, nor should they use other array methods like splice (as seen in an unusual implementation of push and pop in Douglas Crockford’s Remedial JavaScript).

It’s this requirement for independence that causes Internet Explorer to fail a whole slew of tests, and puts it at the back of the pack in terms of standards compliance.

The >>> operator

Working through the push and pop specifications, both methods need to use type-conversion to convert arbitrary (possibly undefined) objects to unsigned 32-bit integers. This can be done using the unsigned right-shift operator (>>>), and this reveals another - trivial - bug: IE5 and Safari fail to ignore particular white-space characters when converting strings to unsigned 32-bit integers. It’s a minor bug, and I hope Safari can be easily fixed by the WebKit guys - Microsoft fixed this particular Internet Explorer bug when they released IE5.5. (testToUint32)

Steps 3 - 6 of push are a little ambiguous, and the specification probably should have stated that repeated increments to n must be done using 32-bit unsigned integer arithmetic - it’s kind-of implicit as n is assigned the result of the internal ToUint32 operator. Using 32-bit arithmetic leads to some strange edge-cases: when n overflows from 2³²-1 to 0, push will have set a property called 4294967295. This is strange, as 429496795 is not an array index (as discussed above), but at least it means the property-value will still be available after the inevitable array-truncation (when length is set to some small value in step 8.)

Although the specification leaves room for the occasional bit of ambiguity, and prescribes some strange behaviour as a consequence, I think it’s well put together. On-screen, it’s not so easy to work with, but Mozilla have produced an improved PDF which includes lots of bookmarks to help navigate through the document.

Dean Edwards recently described a pretty cool technique for enumerating javascript objects, but (currently) it’s not appropriate for sparse arrays. In case you’re unfamiliar with sparse arrays (or I’m using the wrong term), in the language of the Mozilla documentation for Array.forEach, a sparse array is one that’s not “dense”. For example:

// create a three-element array
var array = ['hope', 'empire', 'jedi'];
// add a fourth
array[987654321] = 'menace'; 

// because array length is now 987654322
// this is a really inefficient way of iterating:
for (var i = 0; i < array.length; i++) {
    ... do something ...
}

Iterating over this array using the for loop shown above would mean the loop is executed hundreds of millions of times. That’s terribly inefficient for an array containing so few elements. A more efficient way is to use for (property in object), with an if condition to filter out irrelevant properties:

for (var property in object) {
    if (String(property >>> 0) == property &&
            property >>> 0 != 0xffffffff) {
        ... do something ...
    }
}

The if condition checks whether the property is an array index as defined by the language specification:

A property name P (in the form of a string value) is an array index if and only if ToString(ToUint32(P)) is equal to P and ToUint32(P) is not equal to 2³²−1

That’s it.

1. Uninstall Firefox
2. Delete the (left-over) install folder (e.g. C:\Program Files\Mozilla Firefox)
3. Reinstall Firefox using a custom install (to ensure the DOM Inspector is installed

Knowing that I already had the DOM Inspector installed, I thought I’d try removing just a few files, instead of the whole install folder. Whatever I did worked, and the Style tab works for me now. This more conservative procedure is:

1. Uninstall Firefox
2. Delete only the named inspector* in C:\Program Files\Mozilla Firefox\components
3. Reinstall Firefox using a custom install (to ensure the DOM Inspector is installed

I’m not sure whether the uninstall and reinstall procedure is strictly necessary, so I’m hoping someone out there can try this:

1. Stop Firefox
2. Delete all files named inspector* in C:\Program Files\Mozilla Firefox\components
3. Restart Firefox