«

On Jul 31, 7:43 pm, "Richard Cornford" >

> /* unknown global code */
> function outerFunction(){
> /* unknown outer function body code */
> function innerFunction(){
> /* unknown inner function body code */
> with(anObjectReference){
> x = 5; //<--- The subject line of code.
> }
> /* more unknown inner function body code */
> }
> /* more unknown outer function body code */}
>
> /* more unknown global code */
>
> /* ************************************************** ******\
> | Note: Three facts about the 'unknown' code:- |
> | |
> | 1. There are no more function definitions, no function |
> | expressions and no uses of the Function constructor. |
> | 2. There are no - with - statements in the unknown code.|
> | 3. There are no uses of the - eval - function. |
> \************************************************* ******* */
>
> Q1: Assuming the line that reads - x = 5; - is executed, which (group
> of) of the following are possible outcomes of its execution?
>
> 1. The creation of an 'x' property of the 'outerFunction' function
> and the assignment of the value 5 to that property.

Dunno.

>
> 2. The assignment of the value 5 to a pre-existing 'x' property of
> the 'outerFunction' function.

function outerFunction() {

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}
}


innerFunction()
}
outerFunction.x = 0
var anObjectReference = outerFunction;
outerFunction();


>
> 3. The creation of an 'x' property of the 'innerFunction' function
> and the assignment of the value 5 to that property.

Dunno.

>
> 4. The assignment of the value 5 to a pre-existing 'x' property of
> the 'innerFunction' function.

function outerFunction() {

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}
}

innerFunction.x = 0
var anObjectReference = innerFunction;

innerFunction();

}
outerFunction();


>
> 5. The creation of an 'x' property of the object referred to by
> 'anObjectReference' and the assignment of the value 5 to that
> property.

Dunno.

>
> 6. The assignment of the value 5 to a pre-existing 'x' property of
> the object referred to by 'anObjectReference'.
>

function outerFunction() {

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}
}
innerFunction();
}

var anObjectReference = new Object();
anObjectReference.x = 0;
outerFunction();


> 7. The creation of a local variable of the 'outerFunction' function
> named 'x' and the assignment of the value 5 to that variable.

Dunno.

>
> 8. The assignment of the value 5 to a declared local variable of the
> 'outerFunction' function named 'x'.


function outerFunction() {
var anObjectReference = new Object();
var x;
function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}
}
innerFunction();
}

outerFunction();



>
> 9. The creation of a local variable of the 'innerFunction' function
> named 'x' and the assignment of the value 5 to that variable.

Dunno.

>
> 10. The assignment of the value 5 to a declared local variable of the
> 'innerFunction' function named 'x'.

function outerFunction() {
var anObjectReference = new Object();

function innerFunction() {
var x;
with(anObjectReference){
x = 5; //<--- The subject line of code.
}
}
innerFunction();

}

outerFunction();

>
> 11. The creation of a global variable named 'x' and the assignment of
> the value 5 to that variable.

var anObjectReference = this;

function outerFunction(){

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}

}
innerFunction()
}

outerFunction();

>
> 12. The assignment of the value 5 to a declared global variable
> named 'x'.

var x;
var anObjectReference = this;

function outerFunction(){

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}

}
innerFunction()
}

outerFunction();


>
> 13. The creation of an 'x' property of the global object and the
> assignment of the value 5 to that property.

Same as 11.

>
> 14. The assignment of the value 5 to a pre-existing 'x' property of
> the global object.

Same as 12.

>
> 15. The creation of an 'x' property of the window object and the
> assignment of the value 5 to that property.

Same as 11.

>
> 16. The assignment of the value 5 to a pre-existing 'x' property of
> the window object.

Same as 12.

>
> 17. A runtime error.

var anObjectReference;

function outerFunction(){

function innerFunction() {
with(anObjectReference){
x = 5; //<--- The subject line of code.
}

}
innerFunction()
}

outerFunction();


>
> Q2: If the line of code above is changed from - x = 5; - to - var x =
> 5 - which (group of) the above are then the possible outcomes of the
> execution of that line?

9.

And perhaps that one was a trick question. I'm starting to wonder if
any of the "dunno" scenarios above are even possible.

Since I never use with clauses, this test would be a nightmare for
me. And yes, I verified some of my answers with alerts. All but a
couple were correct (and I corrected those that weren't.)

And aren't with clauses supposed to be taboo in JS?

>
> I would have to go over the answers with the candidate taking the test
> as there are a number of 'understandable mistakes' to be easily made
> here (that is, getting some of them wrong is a certain fail, but others
> may need the thinking behind the answer.)

I figure I failed, but this seems more of an academic exercise than a
practical test (and I am no expert on the guts of ECMAScript.) This
is reinforced by the fact that I haven't used a single with clause in
ten years of scripting Web pages/applications. I've exploited
closures once (thanks to a tip in one of your articles) and I never
nest functions in functions. I've never found a practical need to do
any of these things. Furthermore, using closures, nested functions,
etc. would seem a bad idea if you consider the people who have to
maintain the code in the future (most of whom will likely be the
incompetent clipboard jockeys you alluded to in your preface.)

On Jul 31, 8:21 pm, "Richard Cornford" > > 1. b is a built-in object;
not a String or string literal.

[snip]

> > Define b.
> > if( b ) {
> > alert( "if: " + typeof b );
> > }
> > else {
> > alert( "else: " + b );
> > }
> > result: alerts "if: false"
>
> Given the definition of "built-in object" in ECMA 262, 3rd Ed. Section
> 4.3.7, and especially the words "Every built-in object is a native
> object", and the definition of - typeof - operator in section 11.4.3,
> where all 'native' objects must result in the strings 'object' or
> 'function' when used as a operand of - typeof -, are you sure you are
> not testing for knowledge of implementation bugs here?

Seems like it. That would make it a silly question for a general
JavaScript quiz though. Perhaps it is a trick question and the answer
is "nothing at all."

>
> > 2. Define p and q (they are not Strings). Result:
> > p < q; // false.
> > p <= q; // true.
> > p == q; // false.
>
> What about the execution order of these tests, as a strict adherence to
> the order shown greatly expands the possibilities?
>

I don't understand what you mean by that. I assume the question meant
to define the values once and then evaluate them in whatever order.
Do you mean that you could re-assign p and q in between each test and
come up with virtually infinite possibilities?

On Jul 31, 4:43 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
[snip]

> But then I am very cynical.

At least you know!

> I have the problem of setting javascript technical tests for interviews
> (not that often, but it is part of my job), so form time to time I think
> about what questions they should include, and what I would be looking
> for in an answer.

Given your apparent high standards and opinion of the general quality
of JavaScript programmers, how do these employee searches go for you?
Do you simply take the best applicant or do you wait for a
satisfactory applicant?

> For example, as a verbal question I would tend to ask;
> "which side of an inequality expression is evaluated first?" Not because
> I want to be told the answer (I would not memorise that sort of detail
> (after all, it does not matter 99.9% of the time), and it would scare me
> to encounter someone who did), but because I would want to hear "I would
> have to look it up" (or words to that effect), so I could ask where they
> would look it up, and if given the correct answer hand them a copy of
> the document to see if they were familiar enough with it (and
> interpreting it) to give me the correct answer quickly.

If I was feeling bold and relatively happy with my current job, I
would answer that my code should not depend on knowledge of which side
is evaluated first. That is information that likely anyone would have
to look up and results in code that is not quickly read or easily
maintained.

> On the other hand there are things I would expect someone to know
> (without having to look it up), and one of those is Identifier
> resolution against the scope chain.
>
> "Inspired" by one of the more ambiguous questions on your meebo.com page
> I thought the following might make quite interesting written test
> questions, and give an impression of my thought process in setting
> javascript questions:-
>
> /* unknown global code */
> function outerFunction(){
> /* unknown outer function body code */
> function innerFunction(){
> /* unknown inner function body code */
> with(anObjectReference){
> x = 5; //<--- The subject line of code.
> }
> /* more unknown inner function body code */
> }
> /* more unknown outer function body code */}
>
> /* more unknown global code */
>
> /* ************************************************** ******\
> | Note: Three facts about the 'unknown' code:- |
> | |
> | 1. There are no more function definitions, no function |
> | expressions and no uses of the Function constructor. |
> | 2. There are no - with - statements in the unknown code.|
> | 3. There are no uses of the - eval - function. |
> \************************************************* ******* */

David Mark posted nice answers. I really enjoyed this as an exercise.
I too have never used "with".

I agree with David's sentiment about using "with" as a weeding
technique during the interview process. I think good JavaScript
programmers likely don't use the "with" statement because it is hard
to maintain, prone to creating properties in the wrong place and
cannot be optimized (well?) by the compiler. These warnings about
"with" are plastered all over the place and a good JavaScript
programmer my have never bothered to use "with" before. The places
where I have encountered "with" have been in code that otherwise had
horrendously bad JavaScript and was written by programmers for whom
I've come to have low respect for many reasons.

If you ever feel like posting other interesting exercises please do!

Thanks,
Peter

On Jul 31, 6:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
> On Jul 31, 7:43 pm, "Richard Cornford" >


> > 17. A runtime error.
>
> var anObjectReference;
>
> function outerFunction(){
> function innerFunction() {
> with(anObjectReference){
> x = 5; //<--- The subject line of code.
> }
> }
> innerFunction()
> }
> outerFunction();

I believe the error here isn't coming from the subject line of code
but the line before it.

A runtime error could still occur due to the subject line of
JavaScript. Taking it to the absurd, I have no clue what the
programmer who embedded JavaScript in a particular application has
done with the global x property. It may be that setting the global x
property always results in a runtime error.

> I figure I failed, but this seems more of an academic exercise than a
> practical test (and I am no expert on the guts of ECMAScript.) This
> is reinforced by the fact that I haven't used a single with clause in
> ten years of scripting Web pages/applications. I've exploited
> closures once

Holy cow! What about setting scope for an event, XHR or timeout
callback with objects? Never anything like this...

var thisC;
setTimeout(function() {thisC.callback();}, 1000);

> (thanks to a tip in one of your articles) and I never
> nest functions in functions. I've never found a practical need to do
> any of these things. Furthermore, using closures, nested functions,
> etc. would seem a bad idea if you consider the people who have to
> maintain the code in the future (most of whom will likely be the
> incompetent clipboard jockeys you alluded to in your preface.)

Restraint is in order for sure but no closures or use of higher-order
functions seems like, at the very least, the joy of writing JavaScript
would be completely gone.

Peter

On Aug 1, 12:15 am, Peter Michaux <petermich...@gmail.com> wrote:
[snip]

> David Mark posted nice answers. I really enjoyed this as an exercise.

Thanks Peter. Of course, I didn't read the instructions carefully or
I would have realized that my suspicions about the impossibility of
some of the outcomes were part of the design. I was trying to come up
with code to make each outcome a reality (and gave up on 1, 3, 5, 7
and 9), when I should have taken a cue from the instructions and
expected some of them were going to be impossible. Apparently this
was a true/false exam with an obvious numbering pattern, but I was
treating it like an essay test. In the intended context, all of my
answers to the false questions were wrong as they will certainly be
interpreted as "I don't know if this is true or false."

On Aug 1, 12:46 am, Peter Michaux <petermich...@gmail.com> wrote:
> On Jul 31, 6:35 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > On Jul 31, 7:43 pm, "Richard Cornford" >
> > > 17. A runtime error.
>
> > var anObjectReference;
>
> > function outerFunction(){
> > function innerFunction() {
> > with(anObjectReference){
> > x = 5; //<--- The subject line of code.
> > }
> > }
> > innerFunction()
> > }
> > outerFunction();
>
> I believe the error here isn't coming from the subject line of code
> but the line before it.

Correct. That's one I missed due to not following instructions to the
letter.

>
> A runtime error could still occur due to the subject line of
> JavaScript. Taking it to the absurd, I have no clue what the
> programmer who embedded JavaScript in a particular application has
> done with the global x property. It may be that setting the global x
> property always results in a runtime error.

I don't quite follow you there.

>
> > I figure I failed, but this seems more of an academic exercise than a
> > practical test (and I am no expert on the guts of ECMAScript.) This
> > is reinforced by the fact that I haven't used a single with clause in
> > ten years of scripting Web pages/applications. I've exploited
> > closures once
>
> Holy cow! What about setting scope for an event, XHR or timeout
> callback with objects? Never anything like this...

Yes, I have done that last one recently (technically with
setInterval.) The other thing I use closures for is to associate DOM
events with objects, which is the tip I got from Richard's article on
the subject. But it should be mentioned that that particular
technique will cause a memory leak in IE unless you clean up after it
when the page unloads.

[snip]

> Restraint is in order for sure but no closures or use of higher-order
> functions seems like, at the very least, the joy of writing JavaScript
> would be completely gone.

I find no real joy in writing JavaScript or any other sort of code. I
do enjoy designing and building applications (somewhat), but the
actual coding is drudgery to me.

On 31 , 18:29, Peter Michaux <petermich...@gmail.com> wrote:
>
> http://blog.meebo.com/?page_id=254
>
> Peter

Thanks for link, Peter.

This is interesting but I can't use it . My task is to test
understanding of JavaScript fundamentals and skills to use it in real
life applications. I am not going to reveal concealed gurus

On 1 , 02:43, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:

> When the question of seeking javascript tests on the interment comes up
> my imagination usually conjures up an individual who thinks they will be
> able to get away with using other people's code and copy-pasting their
> way though life, if only they could get a foot through the door.
> Preferably into a job where they were the only person creating the
> javascript, and so not have anyone looking over their shoulders that
> knew what they were doing. The good thing about such a position is that
> the people doing the interview would not know what questions they should
> be asking and so would likely get any technical test they used off the
> Internet themselves. And so a thorough search for such tests, and the
> rote learning of the 'correct' answers, might get them past the
> technical test and into such a job.
>
> But then I am very cynical.
>

Yes, you are. And your accusation is unjust. I am not interviewer. My
task is not to make learner out a fool but to test comprehension of
studied materials. I will never use questions I could not answer
myself. I know JavaScript a little more than my co-workers so I need
to organize teaching. I collected materials to study and I have to
test how they learned it. And before I will start to "invent bicycle"
I asked an advice.

> /* unknown global code */
> function outerFunction(){
> /* unknown outer function body code */
> function innerFunction(){
> /* unknown inner function body code */
> with(anObjectReference){
> x = 5; //<--- The subject line of code.
> }
> /* more unknown inner function body code */
> }
> /* more unknown outer function body code */}
>
> /* more unknown global code */
>
If I were HR manager I most likely do not hire a person who writes
code in that manner. Not because I am afraid of people who know more
than me. Gurus come and go but code leaves. Practice shows that
unmaintable code worse than inefficient code.

On Aug 1, 9:43 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
[...]
> "Inspired" by one of the more ambiguous questions on your meebo.com page
> I thought the following might make quite interesting written test
> questions, and give an impression of my thought process in setting
> javascript questions:-

It seems few others are prepared to attempt a response, so I will.
Fools rush in and all that...


> /* unknown global code */
> function outerFunction(){
> /* unknown outer function body code */
> function innerFunction(){
> /* unknown inner function body code */
> with(anObjectReference){
> x = 5; //<--- The subject line of code.
> }
> /* more unknown inner function body code */
> }
> /* more unknown outer function body code */}
>
> /* more unknown global code */
>
> /* ************************************************** ******\
> | Note: Three facts about the 'unknown' code:- |
> | |
> | 1. There are no more function definitions, no function |
> | expressions and no uses of the Function constructor. |
> | 2. There are no - with - statements in the unknown code.|
> | 3. There are no uses of the - eval - function. |
> \************************************************* ******* */
>
> Q1: Assuming the line that reads - x = 5; - is executed, which (group
> of) of the following are possible outcomes of its execution?

The argument passed to a with statement is first evaluated, then an
attempt is made to see if the result is an object reference. If so, it
is placed at the top of the scope chain. Identifier resolution of the
statement in question then proceeds against this augmented scope
chain.


> 1. The creation of an 'x' property of the 'outerFunction' function
> and the assignment of the value 5 to that property.

Not possible. If a property x is created anywhere by that line, it
will be on the global object.


> 2. The assignment of the value 5 to a pre-existing 'x' property of
> the 'outerFunction' function.

Possible, if anObjectReference does not have an x property.


> 3. The creation of an 'x' property of the 'innerFunction' function
> and the assignment of the value 5 to that property.

Not possible, see answer to 1.


> 4. The assignment of the value 5 to a pre-existing 'x' property of
> the 'innerFunction' function.

Not possible, the innerFunction function object might have an x
property, but it isn't on the scope chain. However, innerFunction's
execution object (which is on the scope chain) may have an x property
if one's been declared and that could be assigned a value.


> 5. The creation of an 'x' property of the object referred to by
> 'anObjectReference' and the assignment of the value 5 to that
> property.

Not possible, see 1.


> 6. The assignment of the value 5 to a pre-existing 'x' property of
> the object referred to by 'anObjectReference'.

Possible, the usual intended result.


> 7. The creation of a local variable of the 'outerFunction' function
> named 'x' and the assignment of the value 5 to that variable.

Not possible, see 1 again.


> 8. The assignment of the value 5 to a declared local variable of the
> 'outerFunction' function named 'x'.

Possible, since that is on the scope chain.


> 9. The creation of a local variable of the 'innerFunction' function
> named 'x' and the assignment of the value 5 to that variable.

Not possible, the creation thing again, see 1.


> 10. The assignment of the value 5 to a declared local variable of the
> 'innerFunction' function named 'x'.

Possible, innerFunction's execution object is on the scope chain.


> 11. The creation of a global variable named 'x' and the assignment of
> the value 5 to that variable.

Possible if x is not encountered sooner in the scope chain, see 1.
Unless you are splitting hairs by saying that properties created this
way aren't variables because they aren't declared, they are just
properties.


> 12. The assignment of the value 5 to a declared global variable
> named 'x'.

Possible, see 11.


> 13. The creation of an 'x' property of the global object and the
> assignment of the value 5 to that property.

Possible, see 11. If all else fails...


> 14. The assignment of the value 5 to a pre-existing 'x' property of
> the global object.

Possible, not much different to 12: declaring x as a global variable
makes it pre-existing to the execution of any code.


> 15. The creation of an 'x' property of the window object and the
> assignment of the value 5 to that property.

Possible, where window === global (which should be always for
browsers), as for 11.


> 16. The assignment of the value 5 to a pre-existing 'x' property of
> the window object.

Possible, see 14 & 15.


> 17. A runtime error.

Possible if anObjectReference isn't an object.


> Q2: If the line of code above is changed from - x = 5; - to - var x =
> 5 - which (group of) the above are then the possible outcomes of the
> execution of that line?

x becomes a property of the innerFunction activation object, the only
possible outcomes are that the value will be assigned to an existing
property anObjectReference, or if that doesn't exist, innerFunction's
declared local x. The resolution of x will proceed no further so no
other outcome will occur.


> I would have to go over the answers with the candidate taking the test
> as there are a number of 'understandable mistakes' to be easily made
> here (that is, getting some of them wrong is a certain fail, but others
> may need the thinking behind the answer.)

Hopefully my explanations are sufficient where the answer itself
isn't.


--
Rob

On Aug 1, 5:32 pm, marss <marss...@gmail.com> wrote:
> On 1 , 02:43, "Richard Cornford" <Rich...@litotes.demon.co.uk>
> wrote:
[...]
> > /* unknown global code */
> > function outerFunction(){
> > /* unknown outer function body code */
> > function innerFunction(){
> > /* unknown inner function body code */
> > with(anObjectReference){
> > x = 5; //<--- The subject line of code.
> > }
> > /* more unknown inner function body code */
> > }
> > /* more unknown outer function body code */}
>
> > /* more unknown global code */
>
> If I were HR manager I most likely do not hire a person who writes
> code in that manner. Not because I am afraid of people who know more
> than me. Gurus come and go but code leaves. Practice shows that
> unmaintable code worse than inefficient code.

That pattern is common where the intention is to emulate private
methods or to encapsulate a library of functions, though it is
normally written something like:

var outerFunction = (function()
{
function innerFunction(){...}

/*
** code that calls innerFunction
*/

})();

The intention of Richard's question is not to encourage any particular
code style or use of the with statement (or even to show off), but to
propose a set of questions to determine someone's understanding of
basic identifier resolution against the scope chain. The use of a
reasonably common code pattern tests if they can apply that knowledge.

It may also test if they can read the ECMAScript Language spec and
apply it, supposing they are as unfamiliar with the with statement as
the great majority of those here seem to be (and I count myself as one
of them).

If you are an HR manager and not a programmer, get someone who you
trust to hire programmers.

What's more dangerous, a manager who codes or a programmer with a
soldering iron?

--
Rob.