• Want to receive the latest contracting news and advice straight to your inbox? Sign up to the ContractorUK newsletter here. Every sign up will also be entered into a draw to WIN £100 Amazon vouchers!

Technical interviews

Also line 2 starts with an opening parentheses. How can a statement begin with an opening parenthesis?

I need a lie down. :freaky:

That is another awesome feature of JavaScript whereby enclosing a function in parens turns it into a function expression, which can then be immediately invoked (turning it into a valid statement).
 
That is another awesome feature of JavaScript whereby enclosing a function in parens turns it into a function expression, which can then be immediately invoked (turning it into a valid statement).

Ok. Seems horribly backwards. Perhaps I need to understand how not typing things and having undeclared functions is a good thing. :laugh

Let me look at the original problem now you have demystified the voodoo for me :oldgit:
 
Happy to do so. Given the following code (JavaScript), the interviewer claimed that "appVar2" needed to be returned from the function expression (using a "return" statement) to make "MyConstructor" available outside the scope of the closure created by the function expression. He claimed that by injecting appVar1 into the function expression it was being copied, implying that appVar2 referred to a separate object, hence the need to return.

This is a fundamental misunderstanding of the way JavaScript uses "pass reference by value" (described more commonly as "pass by reference") when dealing with objects.

Code:
var appVar1 = {};

(function(appVar2){

appVar2.MyConstructor = function() {
//...
};

})(appVar1);

Mock me all you want!

Ok not seeing how appVar1 and appVar2 are in any way related? Can we clear this up before we deal with scope?

Ta.
 
Got it. Ok thanks. All objects are reference types and are held on the heap. Moving onto line 2?

All Objects are reference types but primitives (String, Number, Boolean, null, undefined) are treated as value types (although there are corresponding wrapper Objects for String, Number and Boolean). Placement of strings on stack/heap I suspect involves some clever optimisation (I haven't bothered to ever find out). I wouldn't be surprised if Numbers and Boolean literals are put on the stack directly.
 
Ok not seeing how appVar1 and appVar2 are in any way related? Can we clear this up before we deal with scope?

Ta.

Code:
var appVar1 = {}; //declare object literal (equiv. to "var appVar = new Object();")

//wrap an anonymous function in parens to make it an expression, and then invoke immediately on the final line, passing in appVar1 (visible inside the anonymous function as appVar2)
(function(appVar2){

//create a property named MyConstructor on appVar2 (which is a reference to the same object as appVar1), and assign an anonymous function to it
appVar2.MyConstructor = function() {
//...
};

})(appVar1);

//object "appVar1" now has a new property on it called MyConstructor pointing to the function defined above with the ellipsis inside.
 
Javascript is weird.

So to put it in a less insane way:

Code:
var appVar1 = {};

function fn(appVar2){
appVar2.x = 10;
}
fn(appVar1)

And he doesn't understand that x is now part of appVar1?
 
Ok not seeing how appVar1 and appVar2 are in any way related? Can we clear this up before we deal with scope?

Ta.

Wait, I see it. () is your voodoo on the fly, shot in the arm for unreadable code, function declaration. Appvar2 is the declaration. Appvar1 is the ref, so in theory this is being injected, and the reference holds outside the function declaration.

The constructor function pointer is also set inside the first function declaration.

tulipty question really. To emphasise the manner of object references, there should really be some code after all this performs an operation on appvar1 that was defined on appvar2.

IMVHO.
 
Javascript is weird.

So to put it in a less insane way:

Code:
var appVar1 = {};

function fn(appVar2){
appVar2.x = 10;
}
fn(appVar1)

And he doesn't understand that x is now part of appVar1?

Yes. And this was the worlds largest IBank, and they rejected me. But like an earlier poster said, after the interview I didn't want to work there anyway :)
 
Javascript is weird.

So to put it in a less insane way:

Code:
var appVar1 = {};

function fn(appVar2){
appVar2.x = 10;
}
fn(appVar1)

And he doesn't understand that x is now part of appVar1?

Yes JS is weird.
Yes this is exactly it as I understand it.
 

Advertisers

Back
Top