JavaScript knowledge test

[Peter Michaux]

Hi Rob,

Not that I think I'm a qualified know-it-all but in the spirit of
discussion...

Possible, if anObjectReference does not have an x property.

I think the only way to set a prexisting x *property* of outerFunction
would be if anObjectReference refers to outerFunction. In this case
anObjectReference would have an x property.

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.

If anObjectReference refers to the innerFunction object then the
properties of innerFunction are in the scope chain.

Possible if anObjectReference isn't an object.

But this runtime error isn't due to the subject line of code. It is
due to the line before it.

Peter

 

[Peter Michaux]

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




I don't quite follow you there.

I'm thinking of a non-browser embedding of JavaScript where the
programmer to whom I refer and who has made the embedding has created
a x property of the global object. This programmer can create a
genuine JavaScript runtime error for virtually anything. This isn't a
runtime error due to any of the code in the JavaScript engine (eg
spidermonkey) but it is a JavaScript runtime error nonetheless. Like I
said, this is a relatively absurd answer.

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.

I can understand this sentiment at times However using higher order
functions and to dramatically reduce the amount of code I need to
write and maintain can be a real joy just for the ingenuity of it all.

Peter

 

[Peter Michaux]

"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. |
\******************************************************** */

I started thinking about strings in JavaScript that can be used like
eval() or the function constructor. I think that no use of
setTimeout() or setInterval() with a string first argument should be
added to the list of facts also.

 

[dhtmlkitchen]

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?

Yep. It's pretty straightforward, although if you know of any
implementation bugs, please let us know.

Hint: What are the built-in objects? (process of elimination
strategy).

What about the execution order of these tests, as a strict adherence to
the order shown greatly expands the possibilities?

Richard.

Execution order is irrelevant, so you could have also:
p == q; // false
p <= q; // true
p < q; // false

However, if you do know a way in which execution order would make a
difference, please explain.
Hint: This is a test of how operators work.

 

[Thomas 'PointedEars' Lahn]

"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. |
\******************************************************** */


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.

Not possible. For the creation of a property of a Function object that
object needs to be referenced explicitly.

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

Not possible. For the assignment to a property of a Function object
that object needs to be referenced explicitly.

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

Same here.

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

And here.

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

At least unlikely. The ambiguity in the `with' statement is that it
usually does not apply to assignment statements without a
VariableReference left-hand side. Which is why it is deprecated.

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

Same here.

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. For the creation of local variables requires a local
VariableStatement, however a VariableStatement would make the variable
one of innerFunction().

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

Possible. The innerFunction() function must not have a local `x'
variable then.

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 for the reasons given for 7.

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

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

Possible if neither innerFunction() nor outerFunction() have a variable
with that name declared.

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

Same here.

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

Possible. Global variables are properties of the Global Object, because
that is the Variable Object of the global execution context.

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

Possible if neither innerFunction() nor outerFunction() have a variable
with that name declared.

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

Possible, although the outcome is implementation- and context-dependent.
The host-defined `window' property of the Global Object may not refer
to the Global Object, of which the `x' property would be a property of
under the conditions mentioned for 14.

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

Same here.

17. A runtime error.

Possible if x was not declared before and x is an ID or a name of a DOM
object of the IE DOM (MSHTML component). I can also think of broken
implementations that would not allow a variable to have the same ID or
name as a DOM 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?

9 and 10.

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 am looking forward to your evaluation of my answers.


Regards,
PointedEars

 

[RobG]

Hi Rob,

Not that I think I'm a qualified know-it-all but in the spirit of
discussion...




I think the only way to set a prexisting x *property* of outerFunction
would be if anObjectReference refers to outerFunction. In this case
anObjectReference would have an x property.



If anObjectReference refers to the innerFunction object then the
properties of innerFunction are in the scope chain.

My logic was faulty on both questions - I never considered that
anObjectReference might be to inner/outerFunction. So I got 2 "right"
by accident, and 4 wrong on purpose. I think the tedium got to me!

But this runtime error isn't due to the subject line of code. It is
due to the line before it.

Which means that the line itself is never executed - perhaps a
question along those lines would be more appropriate. It would also
be more difficult to fathom, most people are unlikely to consider
runtime errors as a strategy for preventing particular lines of code
from executing .

 

[Thomas 'PointedEars' Lahn]

I think the only way to set a prexisting x *property* of outerFunction
would be if anObjectReference refers to outerFunction. In this case
anObjectReference would have an x property.

If anObjectReference refers to the innerFunction object then the
properties of innerFunction are in the scope chain.

My logic was faulty on both questions - I never considered that
anObjectReference might be to inner/outerFunction. [...]

However, Peter is mistaken here. The `with' statement does not apply to
the left-hand side of this assignment, no matter the object referenced
with anObjectReference. Unless x is declared, it will always reference
a property of the Global Object, that is a global variable. And so it
will either create that, modify it, or due to the peculiarities of an
execution environment cause a runtime error.


PointedEars

 

[Peter Michaux]

Which means that the line itself is never executed - perhaps a
question along those lines would be more appropriate. It would also
be more difficult to fathom, most people are unlikely to consider
runtime errors as a strategy for preventing particular lines of code
from executing .

Oddly enough . . . I've done this! I considered run-time errors due to
a browser bug/limitation to determine which versions of a particular
old browser could make an XHR POST. This was probably the weirdest
feature test I've ever made but avoided a use of navigator.userAgent.

// NN6.2 can't make POST requests because can't have arguments to
send()
// so now catch NN6.2 and any other browsers that can't take
argument to XHR.send()
function cannotPost() {
var xhr = new XMLHttpRequest();
try {
xhr.send("asdf");
} catch (e) {
// All calls to xhr.send() should error because there wasn't a
call to xhr.open()
// however the normal error is something about "not initialized"
as expected
// since xhr.open() was not called. NN6.2 gives a different
error indicating
// xhr.send() cannot take arguments.
if (-1 !== e.toString().indexOf("Could not convert JavaScript
argument arg 0 [nsIXMLHttpRequest.send]")) {
return true;
}
}
return false;
}


Peter

 

[Peter Michaux]

My logic was faulty on both questions - I never considered that
anObjectReference might be to inner/outerFunction. [...]

However, Peter is mistaken here. The `with' statement does not apply to
the left-hand side of this assignment, no matter the object referenced
with anObjectReference. Unless x is declared,

Richard's #4 states that when the subject line executes that a
innerFunction.x does already exist.

it will always reference
a property of the Global Object, that is a global variable. And so it
will either create that, modify it, or due to the peculiarities of an
execution environment cause a runtime error.

I ran the following in Mac/Firefox2 and it indicates a "yes" to
Richard's statement.

function outerFunction() {
innerFunction.x = 2;
var anObjectReference = innerFunction;
function innerFunction() {
with (anObjectReference) {
x=5;
}
}
innerFunction();
alert(innerFunction.x); // 5
}
outerFunction();

 

[Thomas 'PointedEars' Lahn]

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

[...]
I ran the following in Mac/Firefox2 and it indicates a "yes" to
Richard's statement.

function outerFunction() {
innerFunction.x = 2;
var anObjectReference = innerFunction;
function innerFunction() {
with (anObjectReference) {
x=5;
}
}
innerFunction();
alert(innerFunction.x); // 5
}
outerFunction();

Confirmed for Firefox 2 on Windows XP. Thanks for surprising me.


PointedEars

 

[David Mark]

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

[...]
I ran the following in Mac/Firefox2 and it indicates a "yes" to
Richard's statement.

function outerFunction() {
innerFunction.x = 2;
var anObjectReference = innerFunction;
function innerFunction() {
with (anObjectReference) {
x=5;
}
}
innerFunction();
alert(innerFunction.x); // 5
}
outerFunction();

Confirmed for Firefox 2 on Windows XP. Thanks for surprising me.

You wouldn't be surprised at all if you had read the thread before
posting.

 

[Richard Cornford]

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

Except the letter reads "Assuming the line that reads - x = 5; - is
executed" and an error in the previous line cannot have happened if the
line is executed.

I don't quite follow you there.

The assignment can produces a runtime error when the object being
assigned to is a host object and it throws an exception when the
assignment is made to an 'x' proeperty. Because nothing precludes the
possibility that - anObjectReference - is a host object nothing
precludes the possibility that the assignment will error.

In addition, on IE if no global 'x' variable is declared but an element
exists in the DOM with the ID attribute "x" then IE creates an 'x'
proeprty of the global object and assigns it a reference to the DOM
element. Subsequent attempts to assign to the 'x' property of the global
object then throw exceptions. So if no objects on the scope chain have
'x' properties the exception is thrown when - x = 5 - is resolved as an
assignment to the 'x' property of the global object, and in the event
that the global object were assigned to - anObjectReference - the same
exception whould be thrown with both of - x = 5; - and - var x = 5; -.

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>

No, the code in that article does not produce a memory leak on IE. IE's
memory leak problem has nothing to do with closures as such, it is to do
with circular chains of reference that include JS objects and COM
object. The assigning of the returned inner function form that example
to an intrinsic event property of a DOM node does result in the DOM node
having an indirect reference to a JS object, but so long as the JS
object does not then hold a reference to the DOM node the circle is not
closed and no garbage collection issues follow. The reason that the code
passes a reference to - this - on to the method of the JS object called
is so that the JS object code can have a reference to the DOM node when
it needs one, but does not have to keep one and so provoke the memory
leak issue.

On of the problems with mantra "closures cause memory leaks on IE" is
that it brushes over the fact that circular references can be
established without closures, and doing so is trivial and inherent in
many commonly promoted scripting practices. Another case where knowing
what you are doing is infinitely better than listening to some vague
general advice on scripting.

Richard.

 

[Richard Cornford]

On Jul 31, 4:43 pm, Richard Cornford 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 from
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?

It is not an easy process. If you advertise of expertise you still get a
large proportion of people applying who don't even know the basics (or,
what I would consider to be the basics).

It seems to be a common problem.

Do you simply take the best applicant or do you wait for a
satisfactory applicant?

The potential for extreme and long term harm that can follow form
employing the wrong person is such that nobody gets in unless they
really can do the job, or clearly show the potential to learn the job
very quickly. The "best applicant" is rarely that person.

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 would not necessarily be a bad answer, if you could come up with
something well-reasoned when asked to justify that position.

That is information that likely anyone would have
to look up and results in code that is not quickly read
or easily maintained.

Consider:-

SomeObject.prototype.setState = function(newState){
if(this.state != (this.state = newState)){
// some other code
this.whenStateChanged();
}
};

Is that really difficult to understand? You don't even need to know
which side of the inequality operation is evaluated first in order to
read it, as if it is right hand side first the whole - if - expression
is doomed to always be false and there is no point in having it there at
all. On the other hand, if you were writing this construct it is very
important to get it the right way around, and as we are agreed that
nobody is going to memorise this level of detail it becomes important to
be able to find out the order of evaluation, and preferably find out
with certainty and quickly (less than 30 seconds).

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.

And I think a good javascript programmer knows why we don't use the -
with - statement. That is, knows why the results are "hard to maintain,
prone to creating properties in the wrong place", and for that they need
to know what it does (which is no more than place an object on the top
of the scope chain).

These warnings about "with" are plastered all over the place

But being "plastered all over the place" is hardly any indicator of
truth when it comes to javascript. After all, how often do you read the
assertion that nobody should use closures because closures cause memory
leaks on IE, which is an overly extreme reaction following form a
misrepresentation of the facts. If people read things "plastered all
over the place" they really should be looking to the explanations of why
and how (with critical judgment), and so know what - with - does without
any need actually use it.

and a good JavaScript programmer my have never bothered to use
"with" before.

"May have never bothered" or 'may have never chosen to use (or always
chosen not to use)'? A "good javascript programmer" will be making
informed decisions about what they use, why they use it, and what they
don't use and why they don't use it.

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.

But does that mean you have an excuse for not knowing what - with -
does? What if you had to debug/fix/correct code of that type (code that
is likely be in need of ongoing work by virtue of the quality of its
authoring), you would have to understand it, even if you would never
write it.

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

Of course I will post what I feel like, whenever I feel like it.

Richard.

 

[Richard Cornford]

On Jul 31, 7:43 pm, Richard Cornford wrote:

And perhaps that one was a trick question.

You seem to have missed the second question entirely.

I'm starting to wonder if
any of the "dunno" scenarios above are even possible.

The question is the assessment of which are possible and which are not.

Since I never use with clauses, this test would be a
nightmare for me.

Not using the - with - statement is not a reason for not knowing what it
does (which is simply to add an object to the top of the scope chain)
and the implications of what it does (particularly for the resolution of
Identifiers against that modified scope chain).

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 figure I failed,

Hard to say without all of the answers. You did manage to spot how the
value might get assigned to 'x' properties of the function objects,
which is counter intuitive and so something I would not be surprised to
see go unobserved. And the point of such a test is expose the boundaries
of someone's understanding, for which it is necessary to try to pitch a
few shots over the target.

but this seems more of an academic exercise than a
practical test

It is certainly in their nature for technical tests to look like
academic exercises. The practical purposes they serve are the purposes
of the people asking the questions.

(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.

But do you understand why you don't use them? That is an implied part of
the question I asked. The use of - with - statement is strongly
discouraged precisely because some of the outcomes where it is used are
distinctly counterintuitive, and that makes for hard to understand, and
so difficult/expensive to maintain code.

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.)

That is an oft-repeated position, though I don't think its proponents
have considered what the consequences are if the limits imposed upon the
creation of javascript are that the results should always be
comprehendible to the ignorant and incompetent.

Did you notice the post advertising http://www.wikicodia.com last week?
Go to the home page of that site and look at the script they have there;
evidence of an author who does not know what a local variable is,
doesn't know how, when and why to use them, and has created a script
that has wrapped needless javascript dependency round what must be
completely viable server-side search facility for the sake of a trivial
gimmick. And I should limit my code to this level just so this
individual will not be obviously out of his depth in the event that some
fool is reckless enough to employ him to maintain it?

Richard.

 

[Richard Cornford]

On Jul 31, 8:21 pm, Richard Cornford wrote:


I don't understand what you mean by that.

In the event that either one value is the primitive null value and the
other is zero or false (the empty string being precluded by the stated
condition), then the tests will produce the results shown. In addition,
if p and q are distinct objects and the - valueOf - or (if they don't
use the default object - valueOf - methods, or similar) - toString -
methods are defined such that one returns a null value and the other
returns one of zero, false, or the empty string (which is not precluded
by the conditions as the p and q values are objects) then you also get
shown results.

So in addition to the 4 possible permutations of primitive values that
are correct answers to the question there are an infinite number of
possible answers using objects, a simple example of which might be:-

p = {valueOf:function(){return null;}};
q = {valueOf:function(){return '';}};

However, if the tests are applied in a specific order then you can
include Object where the - valueOf - or - toString - methods return
values that differ sequentially to satisfy the test being made. Adding
another infinite number of possibly correct answers to the list. Hence
"greatly expands the possibilities".

I assume the question meant to define the values once and
then evaluate them in whatever order.

There is great danger in reading more into statements than they state.
It is the sort of thinking that has had people making multi-million
dollar space probes and then using them to discover that the surface of
Mars is not really that bouncy. If a specification is not sufficiently
specific it is invariably best to ask for clarification.

Do you mean that you could re-assign p and q in between each
test and come up with virtually infinite possibilities?

No, I don't see how p or q could be re-defined/re-assigned give the
conditions in the question ("Define p and q" being singular), but I have
could come up with infinite possibilities anyway.

Richard.

 

[David Mark]

Except the letter reads "Assuming the line that reads - x = 5; - is
executed" and an error in the previous line cannot have happened if the
line is executed.

Isn't that what I said? My example got it wrong as it caused an error
in the wrong line.

The assignment can produces a runtime error when the object being
assigned to is a host object and it throws an exception when the
assignment is made to an 'x' proeperty. Because nothing precludes the
possibility that - anObjectReference - is a host object nothing
precludes the possibility that the assignment will error.
Okay.


In addition, on IE if no global 'x' variable is declared but an element
exists in the DOM with the ID attribute "x" then IE creates an 'x'
proeprty of the global object and assigns it a reference to the DOM

That's odd.

element. Subsequent attempts to assign to the 'x' property of the global
object then throw exceptions. So if no objects on the scope chain have
'x' properties the exception is thrown when - x = 5 - is resolved as an
assignment to the 'x' property of the global object, and in the event
that the global object were assigned to - anObjectReference - the same
exception whould be thrown with both of - x = 5; - and - var x = 5; -.

That's stranger still. Suffice to say that you wouldn't use the code
in this test in a production environment as it would be a nightmare to
maintain.

<snip>

No, the code in that article does not produce a memory leak on IE. IE's
memory leak problem has nothing to do with closures as such, it is to do
with circular chains of reference that include JS objects and COM
object. The assigning of the returned inner function form that example

Right. I was being over-cautious in cleaning up all such events on
unload. In practice they often do create circular references (eg the
object has an "element" property that references the element with the
attached event), but not always.

to an intrinsic event property of a DOM node does result in the DOM node
having an indirect reference to a JS object, but so long as the JS
object does not then hold a reference to the DOM node the circle is not
closed and no garbage collection issues follow. The reason that the code
Right.

passes a reference to - this - on to the method of the JS object called

Interesting that you mention that. I recall that I had some
difficulty getting that part to work as expected (though perhaps I
wasn't expecting the right thing.)

is so that the JS object code can have a reference to the DOM node when
it needs one, but does not have to keep one and so provoke the memory
leak issue.

That makes sense.

On of the problems with mantra "closures cause memory leaks on IE" is

That is no mantra of mine.

that it brushes over the fact that circular references can be
established without closures, and doing so is trivial and inherent in

Right. It just so happens that the cited example of attaching DOM
events to object methods uses closures and is always one line of code
away from establishing a memory leak in IE.

 

[David Mark]

Isn't that what I said? My example got it wrong as it caused an error
in the wrong line.

Correction. Since all of my answers were technically not the
requested "possible/impossible" answers, but code examples, I got them
all wrong (at least for Q1.) Since it turns out that the error is
possible after all (though in a way I would not have foreseen), then
my type-converted answer (possible) is correct.

Applying the type-conversion, I see the answer key as:

Q1
1. Not possible
2. Possible
3. Not possible
4. Possible
5. Not possible
6. Possible
7. Not possible
8. Possible
9. Not possible
10. Possible
11. Possible
12. Possible
13. Possible
14. Possible
15. Possible
17. Possible

Q2 (multiple choice)
9.

Most of the other posters had similar takes. What are the correct
answers as you see them?

 

[zeroglif]

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

function outerFunction() {
var anObjectReference = outerFunction;
Function.prototype.x = 0;
function innerFunction() {
with (anObjectReference) {
x = 5;
}
}
innerFunction();
}
outerFunction();


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

function outerFunction() {
function innerFunction() {
var anObjectReference = innerFunction;
Function.prototype.x = 0;
with (anObjectReference) {
x = 5;
}
}
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.

function outerFunction() {
function innerFunction() {
var anObjectReference = {};
Object.prototype.x = 0;
with (anObjectReference) {
x = 5;
}
}
innerFunction();
}
outerFunction();

 

[Richard Cornford]

:

I am looking forward to your evaluation of my answers.

I hope you and everyone else who has had a go doesn't mind if I leave
going into my version of the answers for a couple of days (probably the
weekend). That should give everyone who wants to a chance to have a go,
and revise their answers if they have reason to re-evaluate them.

Richard.

 

[Richard Cornford]

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

[...]
I ran the following in Mac/Firefox2 and it indicates a
"yes" to Richard's statement.

function outerFunction() {
innerFunction.x = 2;
var anObjectReference = innerFunction;
function innerFunction() {
with (anObjectReference) {
x=5;
}
}
innerFunction();
alert(innerFunction.x); // 5
}
outerFunction();

Confirmed for Firefox 2 on Windows XP. Thanks for
surprising me.

I am surprised that you are surprised by that one (David showed that
this morning). The one that is likely to get the attention is the proof
that #1, #3 and #5 are possible (clue: the wording is deliberately
precise)

Richard.