Do you know your JavaScript? Take a look at the following code sample and work out what value is shown in the final alert statement …
// object constructor
function ObjectConstructor(a, b, c) {
this.A = a;
this.B = b;
this.C = c;
this.Total = a + b + c;
}
var obj = ObjectConstructor(1, 2, 3);
alert(obj.Total);
Hands up everyone who answered “6.”
Sorry, you’re wrong. The answer is … nothing — or an error stating that ‘obj’ is undefined. So what’s gone wrong?
The simple answer is that we’ve forgotten the ‘new’ operator so an object instance is never created. The statement should be:
var obj = new ObjectConstructor(1, 2, 3);
It’s an easy mistake to make. Novice developers are unlikely to spot the missing operator because the code looks almost identical. Even experienced coders could find it tough to debug (especially since many assume JavaScript is a procedural programming language … which it can be, if you choose to write it that way).
The main problem is that var obj = ObjectConstructor(1, 2, 3); is a perfectly valid JavaScript statement and the interpretor engine will not throw an error. In that context, the value of obj is set to the value returned from the function ObjectConstructor; since no value is returned, obj remains “undefined” (a top-level JavaScript property).
This is unlikely to become a major problem if you’re developing, testing and debugging your own code. However, it could be a different matter when you’re providing a library or API to thousands of third-party developers. At some point, someone, somewhere, will miss that ‘new’ operator and they will blame your code rather than theirs.
Fortunately, JavaScript is a flexible language. We can fix our constructor so an object is correctly created even when the ‘new’ operator is omitted:
// object constructor
function ObjectConstructor(a, b, c) {
if (!(this instanceof arguments.callee)) {
return new ObjectConstructor(a, b, c);
}
this.A = a;
this.B = b;
this.C = c;
this.Total = a + b + c;
}
The additional ‘if’ statement at the top of the constructor checks whether ‘this’ is an instance of the object and returns one if necessary. The code var obj = ObjectConstructor(1, 2, 3); will now set obj to an object instance and “6″ will be output by the alert statement.
Have you ever encountered this problem in your code or when using another library?
Related posts:
- Cross-browser JSON Serialization in JavaScript JSON serialization can be incredibly useful, but few browsers support...
- Truthy and Falsy: When All is Not Equal in JavaScript Anything in JavaScript can be considered to be either truthy...
- How to Write a Cookie-less Session Library for JavaScript Craig provides the code for a stand-alone JavaScript session variable...
- Google Closure: How not to write JavaScript What if Google released a JavaScript library that sucked, and...
- Implementing Event Latency in JavaScript Craig provides some useful JavaScript code to slow down event...
That is an interesting solution. Personally, I think I’m more for alerting a debug error when bad code is written, rather than writing a solution that makes bad code work, but this is pretty darn clever.
October 21st, 2009 at 2:15 am
I personally prefer to solve problems like this with the Yahoo Module pattern, but anyway – thanks for sharing! Great tip.
October 21st, 2009 at 2:25 am
Hi madr,
The module pattern has a slightly different use — it’s a singleton encapsulated in a module that cannot conflict with any other modules. You could still create objects within those modules or expose them so they can be used by other code/modules.
October 21st, 2009 at 3:20 am
It might be worth mentioning that arguments.callee is not allowed in ECMAScript 5th edition strict mode.
October 21st, 2009 at 4:05 am
I have to be honest I’ve never run into this problem. “new” is basic OOP. You’re simultaneously providing a failsafe against an object quirk in JS using an advanced technique that only people who wouldn’t have this problem to begin with could understand.
Odds are if you are using faux objects in JS, you already understand “new”, and that’s a generous assessment.
They aren’t broken, either. The reason that original code works is to support JS’s event syntax which allows such things as
object.onEvent = function(){...}October 21st, 2009 at 5:54 am
It’s a nice tip, but I agree with Jasconius.
A benefit of having the “new” keyword is that it shows you a new instance is being created and can help with readability (and understanding by others).
October 21st, 2009 at 6:31 am
@Jasconius
This could be useful in code that will be shared. Anyone using jQuery (and probably some other libraries) are already using techniques of this type. jQuery’s is based around the $ object, but you don’t need to add ‘new’ to use it.
October 21st, 2009 at 6:44 am
Nice :)
… might you also want to cover then the typing of the variables and use the assigned variables in the this.Total attribute?
e.g, what if somewhere in the app the following variables are created at various points:
var x = 1;
var y = ‘2′;
var z = 3;
Then, a bit later you use the constructor:
var obj = ObjectConstructor(x, y, z);
Above you’d get an alert of “123″, like this, you might avoid these potential problems as well:
function ObjectConstructor(a, b, c) {
if ( !( this instanceof arguments.callee ) ) {
return new ObjectConstructor( a, b, c );
}
this.A = parseFloat(a);
this.B = parseFloat(b);
this.C = parseFloat(c);
this.Total = this.A + this.B + this.C;
}
October 21st, 2009 at 6:54 am
For those that are concerned about furthering poor coding practices, you could always change the constructor challenge to something like:
if ( !( this instanceof arguments.callee ) ) { return new ObjectConstructor( a, b, c ); }October 21st, 2009 at 7:35 am
For those that are concerned about furthering poor coding practices, you could always change the constructor challenge to something like:
if ( !( this instanceof arguments.callee ) ) { alert("You must instantiate this object with the 'new' keyword."); }October 21st, 2009 at 7:36 am
I think only half the problem is explained, it’s not just that you don’t have an object ref , it’s also now that you have added all the properties in the object to the global window object. Run the script and call alert with window.Total as the argument. Ta Da..
October 21st, 2009 at 9:42 am
Nice tgoyer :)
.. and might as well throw it as an error then
if ( !( this instanceof arguments.callee ) ) { throw( "You must instantiate this object with the 'new' keyword." ); }which would be caught with something along the lines of:
try { var obj = ObjectConstructor(x, y, z); } catch(e) { // use pre-defined error handler method or ... alert(e); }October 21st, 2009 at 1:03 pm
Throwing or alerting an error is a vastly better idea than trying to second-guess the intended syntax. I appreciate what you’re trying to do Craig, but you could create as many problems as you solve with an approach like that.
October 21st, 2009 at 6:54 pm
I like the idea of throwing an error, but would avoid alerts incase you’re creating many instances quickly – next stop alert-hell!
October 21st, 2009 at 8:45 pm
I agree with tgoyer. The alert would be a much better option. While the code is an interesting fix, it promotes bad coding. I’d rather people who think they can create an object with “new” would just learn that they need to use “new”. I spotted the error right away. For a second I thought, hmm, maybe Javascript allows object creation with the “new” keyword, then I read on.
October 21st, 2009 at 9:11 pm
What is the world coming to? Programmers are introducing additional code to help other programmers who can’t program? I’m going in the opposite direction: trying to remove bloat from my client-side coding and make it more efficient.
As others have said, at least just throw an error if you’re going to do this, but otherwise let them read a book on programming and test their code. If they can’t work out when to use the ‘new’ operator there’s probably worse things going wrong too.
October 22nd, 2009 at 7:52 am
The demands of each application will be different. If it’s your own internal code, you don’t need this ‘fix’. If you’re providing a complex API to proficient developers, an error may be more appropriate.
However, a jQuery-like library open to anyone could benefit from the technique. If a problem’s fixable, why not do so? After all, we developers can not be held responsible for the bad coding practices of others … but we do have a duty to minimize the level of support required for our products.
October 22nd, 2009 at 9:33 pm
Why not do so? Because the fix may be worse than the original problem. You’re still second-guessing what was intended.
What if the user intended to refer to the object constructor and not to create an instance, for example, to create a reference to it.
October 22nd, 2009 at 11:03 pm
I’m not disagreeing that you should be careful with changing the way the language behaves, but could you expand on this point?
Creating a reference still works:
// Make a reference to the constructor var objRef = ObjectConstructor; // Next 2 statements are equivalent var obj1 = objRef(1, 2, 3); var obj2 = new objRef(1, 2, 3);Of course, if you actually expect the function to do something else, you wouldn’t get anything. But that’s the case, references or not. References are not broken under this scheme.
October 23rd, 2009 at 12:21 am
Damm new lines are gone (looked correct in preview):
// Make a reference to the constructor var objRef = ObjectConstructor; // Next 2 statements are equivalent var obj1 = objRef(1, 2, 3); var obj2 = new objRef(1, 2, 3);October 23rd, 2009 at 12:23 am
As mentioned, this is not a solution for all projects. However, we all implement code that validates, fixes or sets defaults for parameters — is this solution much different? At the very minimum, it will reduce your support burden and that’s never a bad thing.
If I understand brothercake correctly, he’s saying that we’re making an assumption about what the developer’s doing. However, in this case, there’s little ambiguity. A reference can still be made, but any call using parenthesised arguments must always create a new object. We never want this constructor to run as a function and implementing the fix stops that happening.
October 23rd, 2009 at 9:38 pm
Since You/we/me are developers of a library, assumption is we should know better then library users ?
function X (a_,b_,c_) { return { a : a_, b :b_, c : c_, total : a_ + b_ + c_ } } ; (new X(1,2,3).total) === (X(1,2,3).total) /* true */Therefore we will use correct development idioms, to shield ourselves in a most efficient way, from possible incorect use of our library.
November 12th, 2009 at 10:51 pm
@DBJ.ORG Your solution returns an object of type object, not of type X, therefore hindering the use of instanceof and inheritance.
–
This is a valid solution, overkill for internal projects, but useful for libraries to keep your users from shooting themselves in the foot. You should do it anytime you don’t need major hacks. However, the solution as stated requires copy/pasting of code into every constructor, ouch!
November 19th, 2009 at 2:35 am