«

On Aug 1, 5:59 pm, Thomas 'PointedEars' Lahn <PointedE...@web.de>
wrote:
> Peter Michaux wrote:
> > | 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.

On Aug 1, 6:42 am, David Mark wrote:
> On Aug 1, 12:46 am, Peter Michaux wrote:
>> On Jul 31, 6:35 pm, David Mark wrote:
>>> On Jul 31, 7:43 pm, Richard Cornford wrote:
>>>> 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.

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.

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

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

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

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.

On Aug 1, 5:15 am, Peter Michaux wrote:
> 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.

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

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

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.

On Aug 1, 2:35 am, David Mark wrote:
> On Jul 31, 7:43 pm, Richard Cornford wrote:
<snip>
>> 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?
>
> 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 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,

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.

On Aug 1, 2:48 am, David Mark wrote:
> On Jul 31, 8:21 pm, Richard Cornford wrote:
<snip>
>>> 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.

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.

On Aug 1, 7:04 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
> On Aug 1, 6:42 am, David Mark wrote:
>
>
>
>
>
> > On Aug 1, 12:46 am, Peter Michaux wrote:
> >> On Jul 31, 6:35 pm, David Mark wrote:
> >>> On Jul 31, 7:43 pm, Richard Cornford wrote:
> >>>> 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.
>
> 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.

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

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

On Aug 1, 7:18 pm, David Mark <dmark.cins...@gmail.com> wrote:
>
> > 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.
>

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?

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();

"Thomas 'PointedEars' Lahn" wrote:
<snip>
> 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.

Thomas 'PointedEars' Lahn wrote:
> Peter Michaux wrote:
>> | 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.