JavaScript knowledge test

[marss]

Maybe anyone know good free online JavaScript knowledge test? This not
exactly a system for testing online required - it may be simply list
of questions with variants of answers (I have to prepare tests for
learners and I need something to be taken as basis).

I was able to find only this (http://www.w3schools.com/js/
js_quiz.asp), but I need more.

Thanks,
Mykola

[Peter Michaux]

On Aug 2, 9:39 am, Henry <[e-mail]:

On Aug 2, 4:22 pm, Peter Michaux wrote:

Is definition 4.3.4 even correct?

"A constructor is a Function object that creates and initializes
objects. Each constructor has an associated prototype object that is
used to implement inheritance and shared properties."

That is a definition that makes every single function (with the
exception of the build-in functions such as - parseInt - and - eval -
(because they don't have prototypes)) into constructors, which is
fine, and answers the question about Function.

If the definition is to make all functions "constructors" then it
should say something like "A constructor is a Function object that can
create...." The word "can" is missing and I read the definition to
mean "A constructor is a Function object that does create...." I think
the "creates" in the definition means that the function is called with
|new| at least once.

Peter

[Peter Michaux]

On Aug 1, 5:41 pm, "Richard Cornford" <[e-mail]>
wrote:

Peter Michaux wrote:

On Aug 1, 4:36 pm, Richard Cornford wrote:

Peter Michaux wrote:

<snip>

> // xhr.send() cannot take arguments.
if (-1 !== e.toString().indexOf("Could not convert JavaScript
argument arg 0 [nsIXMLHttpRequest.send]")) {

<snip>

Did you try (if they actually exist) versions in other
languages? ..

<snip>

In other languages? You mean JScript vs JavaScript?

<snip>

No, I meant languages like German, Spanish and Japanese. You are doing a
comparison with a phrase in English, if the phrase is available in
translation in other countries then the comparison will fail.

I seem to recall that they only did English versions of the early
Netscape 6s so you are probably OK here, but the issue exists with
try-catch and error handling in general, which is why defensive
programming to avoid errors (and so the need to attempt to handle them)
seems the better idea.

I did a little research and there were other language releases

http://browser.netscape.com/downloads/archive/

I downloaded the French release of v6.2 and the error message is in
English so presumably they didn't translate JavaScript errors in any
language release.

This wasn't a fresh install of windows so if there was some JavaScript
engine interferance from one version to another my results may be
meaningless. I will eventually make a fresh Windows install and
retest. Thanks for the tip, Richard.

Peter

[Richard Cornford]

On Aug 2, 4:40 pm, [e-mail] wrote:

On Jul 31, 6:48 pm, David Mark <[e-mail]:

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

>>On Aug 2, 4:40 pm, [e-mail] wrote:
1. b is a built-in object; not a String or string literal.

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

No,

The answer could be: new Object("false"), new Object(false);
Is this a bug?

If the code - alert( "if: "+ typeof b ); - results in the alerting of
"if: false" when - b - is either of - new Object("false") - or - new
Object(false) - then that most definitely is a bug. The specified result
of the - typeof - operation would be the string "object".

In addition (and if I can be bothered to look-up the section numbers for
you the least you could do is read them) the detention of Built-in
objects reads:-

| A built-in object is any object supplied by an ECMAScript
| implementation, independent of the host environment, which
| is present at the start of the execution of an ECMAScript program.
| Standard built-in objects are defined in this specification, and an
| ECMAScript implementation may specify and define others. Every
| built-in object is a native object.

- and the results of both of - new Object("false") - and - new
Object(false) - fail to satisfy the condition of being "present at the
start of the execution of an ECMAScript program". So they are not
built-in objects.

It looks to me like your intended code would have been - alert( "if: "+
b ); - and you were trying to point out that the type-conversion to
string values of some objects, which are true (or have trueness) by
virtue of being objects, may still be the string "false".

It is a pity that all my talk of the - typeof - operator did not tip you
off that something must be up.

Now if you were looking for a built-in object that had these
characteristics the - Boolean.prototype - would satisfy that
requirement, being an instance of the Boolean object with a 'false'
value, and existing from the start of the execution of an ECMAScript
program.

Of course a question to which the answer was - Boolean.prototype - would
not come well from someone who objected to questions using - with - on
the grounds that they did not ever use - with -, because I have seen
people using - with - but I am yet to any real code contain any
references to - Boolean.prototype -.

new Boolean( false ); will produce the same result in
IE and in FF, I think this is a bug.

It is not a bug. The specification requires - new Object(false) - to be
the exact equivalent of - new Boolean(false) - and - new
Object("false") - to be the exact equivalent of - new String("false") -.
So if your "b is a ... ; not a String or string literal" where taken as
referring to String objects and string primitives then - new
Object("false") - would not be allowed anyway (the resulting value is a
String object).

Richard.

[Richard Cornford]

Peter Michaux wrote:

On Aug 1, 4:04 pm, Richard Cornford wrote:

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

Just out of curiosity

Don't get too curious, confidentially clauses apply.

to which types of "extreme and
long term harm" can result from JavaScript at your
company?

Bankruptcy, unemployment for all the staff. We are in a business where
there are not that many potential customers world-wide so acquiring a
reputation for delivering faulty software would not be likely to go
unnoticed in our market place. Fortunately very little gets past our QA
department.

When boiled down, most
JavaScript jobs involve widgets and XHR requests.

Yes, if you wanted to boil it down that way that is my job precisely.

I get the impression that you get to do something
more risky/interesting.

Interesting has got to be very relative. I wouldn't do the job if it
wasn't interesting, but I do get to design at the architectural level.

Risky, on the other hand, is not my perception if my job. Worst-case I
get to work for someone else. There are at least big 3 city of London
banks at the moment struggling to find people to work on large "AJAX"
systems for them (and have been for the last couple of years).

I had a much greater perception of risk when I used to work in financial
services (server-side Java programming), where it was made very clear,
and often repeated, that there was no margin for getting things wrong at
all. And I often remember the incident were a single line of faulty code
resulted in an erroneous automated purchase of £48,000 of shares, cost
our client more then the programmer who wrote the line earned in a year
and was only forgiven by our management because the fault had been
spotted/corrected before it has cost anyone any 'real money'.

Richard.

[Richard Cornford]

dh**********@gmail.com wrote:

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

<snip>

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

I really do not like the 'with' statement.

This question looks familiar.

It would be purely coincidental if it was.

You don't by chance work at Google, richard?

There is no need to get abusive ;-)

<snip>

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

This will confuse people who don't use 'with'

No, it may confuse the people who don't understand the - with -
statement. The people who do understand the - with - statement don't
(necessarily) use it but will not have a problem understanding its
implications.

It's another reason I don't like 'with'; it looks like
this might happen, but instead, the property won't be
created on anObjectReference, but will be set, if it
is found.

So that would be a 'not possible' then?

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

Another reason why 'with' should be avoided. It serves
only to confuse.

I think that:
- the inner function will get a new local variable.
- anObjectRef.x won't get updated

There seems to be a great deal of reluctance to go into detail on the
second question. To my mind the candidate's understanding of how the
possibilities change with the use of the - var - statement would be very
telling.

You have answered that #9 is possible and that #6 is not possible, but
your opinions on the rest are unstated.

It would seem that x would be a new variable in a scope
block, but with doesn't create a scope block, it instead
conflates the current scope block.

"Scope block" is terminology unconnected with anything in javascript. As
such it can mean anything to anyone who reads it, or mean nothing at
all. With "conflate" meaning "to fuse; to combine into one; (literally)
to blow together" and applied to whatever a "scope block" is supposed to
be, there doesn't seem to much connection here with what a - with -
statements actually does and "conflates the current scope block". It all
sounds like VKesque BS to me, and like his probably belies a fundamental
misconception. It serves only to confuse.

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

<snip>

I got an interview question just like this before.

Do we take it that was with Google? The quality of the javascript they
write would make that a surprising fact.

The interviewer was focused on details of the with statement
and scope and the cleverness of his question.

<snip>

So you didn't get the job then?

Richard.

[dhtmlkitchen]

On Aug 2, 9:56 am, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[e-mail] wrote:

David Mark wrote:

Richard Cornford wrote:
[e-mail] wrote:
1. b is a built-in object;
not a String or string literal.
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."

No,

The answer could be: new Object("false"), new Object(false); Is this a
bug?

^
Why would that be an answer at all?

new Boolean( false ); will produce the same result in IE and in FF,

Which is `object' (typeof Boolean(false)).

I think this is a bug.

It's not a bug. There is a difference between Boolean objects and
primitive boolean values. Any valid object reference type-converts to
true, so the first branch is taken. Passing `false' to the Boolean
constructor does not change the fact that an object is created, and a
reference to it is returned.

ISTM you have misunderstood Richard. He meant that you expect the
typeof-Operation on a native object to yield "false", which would be an
implementation bug (or at least a language extension) if it occurred.

Yeah, you're right.

PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not the
best source of advice on designing systems that use javascript.
-- Richard Cornford, <f806at$ail$1$[e-mail]>

[dhtmlkitchen]

On Aug 2, 12:51 pm, "Richard Cornford" <[e-mail]>
wrote:

On Aug 2, 4:40 pm, [e-mail] wrote:

On Jul 31, 6:48 pm, David Mark <[e-mail]:

On Jul 31, 8:21 pm, Richard Cornford
On Aug 2, 4:40 pm, [e-mail] wrote:
1. b is a built-in object; not a String or string literal.

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

No,

The answer could be: new Object("false"), new Object(false);
Is this a bug?

If the code - alert( "if: "+ typeof b ); - results in the alerting of
"if: false" when - b - is either of - new Object("false") - or - new
Object(false) - then that most definitely is a bug. The specified result
of the - typeof - operation would be the string "object".

In addition (and if I can be bothered to look-up the section numbers for
you the least you could do is read them) the detention of Built-in
objects reads:-

| A built-in object is any object supplied by an ECMAScript
| implementation, independent of the host environment, which
| is present at the start of the execution of an ECMAScript program.
| Standard built-in objects are defined in this specification, and an
| ECMAScript implementation may specify and define others. Every
| built-in object is a native object.

- and the results of both of - new Object("false") - and - new
Object(false) - fail to satisfy the condition of being "present at the
start of the execution of an ECMAScript program". So they are not
built-in objects.

You're right.

It looks to me like your intended code would have been - alert( "if: "+
b ); - and you were trying to point out that the type-conversion to
string values of some objects, which are true (or have trueness) by
virtue of being objects, may still be the string "false".

It is a pity that all my talk of the - typeof - operator did not tip you
off that something must be up.

No need for the pity! I just didn't read that post yet. It's a lot to
keep up w/here. I'm in SF now, weather is good. I do go out
sometimes :D

Now if you were looking for a built-in object that had these
characteristics the - Boolean.prototype - would satisfy that
requirement, being an instance of the Boolean object with a 'false'
value, and existing from the start of the execution of an ECMAScript
program.

Of course a question to which the answer was - Boolean.prototype - would
not come well from someone who objected to questions using - with - on
the grounds that they did not ever use - with -, because I have seen
people using - with - but I am yet to any real code contain any
references to - Boolean.prototype -.

Cool! So that is the answer, and it does fulfill the 'built-in' req.
Sorry for leading you all astray with the Object constructor.

That was actually what I thought at first (Boolean object), but then
when I read the steps for evaluating an 'if' statement, I saw that it
called GetValue. I'm not understanding how GetValue works; does it try
to take the object as a variable from the containing scope? I don't
get it. Someone esplain, please.

I've debugged code like this. At a prominent company in Sunnyvale, I
found code that used the Boolean constructor in a conditional. It was
as if they wanted if(!!maybeUndefined), but instead used if( new
Boolean( maybeUndefined ) ). But definitely not a common case, you're
right.

I learned a lot about debugging others' code there. The Boolean thing
was just one small anomaly. Fortunately, they were pretty patient with
me and didn't take my code fixes too personally.

I've seen 'with' but only for simple examples, and not in any recent
code.

new Boolean( false ); will produce the same result in
IE and in FF, I think this is a bug.

It is not a bug. The specification requires - new Object(false) - to be
the exact equivalent of - new Boolean(false) - and - new
Object("false") - to be the exact equivalent of - new String("false") -.
So if your "b is a ... ; not a String or string literal" where taken as
referring to String objects and string primitives then - new
Object("false") - would not be allowed anyway (the resulting value is a
String object).

Ah, that would explain why:
typeof new Object( "foo" );//Object
new Object( "foo" ).constructor // String

What a funny language.

Richard.

[Richard Cornford]

Richard Cornford wrote:

dh**********@gmail.com wrote:

<snip>

<snip>

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

This will confuse people who don't use 'with'

No, it may confuse the people who don't understand the - with -
statement. The people who do understand the - with
- statement don't (necessarily) use it but will not have
a problem understanding its implications.

<snip>

And of course it is also the case that some (possibly the majority of)
of the people who do use the - with - statement do not understand what
it does. They may or may not experience confusion, but they will likely
be wrong regardless.

Richard.

[Thomas 'PointedEars' Lahn]

[Trimmed quote, see
http://www.jibbering.com/faq/faq_notes/clj_posts.html and
http://netmeister.org/news/learn2quote.html]

dh**********@gmail.com wrote:

[...] "Richard Cornford" [...] wrote:

>[...] [e-mail] wrote:

>>new Boolean( false ); will produce the same result in
IE and in FF, I think this is a bug.

It is not a bug. The specification requires - new Object(false) - to be
the exact equivalent of - new Boolean(false) - and - new
Object("false") - to be the exact equivalent of - new String("false") -.
So if your "b is a ... ; not a String or string literal" where taken as
referring to String objects and string primitives then - new
Object("false") - would not be allowed anyway (the resulting value is a
String object).

Ah, that would explain why:
typeof new Object( "foo" );//Object
new Object( "foo" ).constructor // String

What a funny language.

The author of JavaScript himself is not quite happy with the type
distinction between primitive types like boolean and string, and object
types like Boolean and String:

http://weblogs.mozillazine.org/roadm...05/11/js2.html
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[dhtmlkitchen]

On Aug 2, 11:32 pm, Thomas 'PointedEars' Lahn <[e-mail]>
wrote:

[Trimmed quote, seehttp://www.jibbering.com/faq/faq_notes/clj_posts.htmlandhttp://netmeister.org/news/learn2quote.html]

[e-mail] wrote:

[...] "Richard Cornford" [...] wrote:

[...] [e-mail] wrote:
new Boolean( false ); will produce the same result in
IE and in FF, I think this is a bug.
It is not a bug. The specification requires - new Object(false) - to be
the exact equivalent of - new Boolean(false) - and - new
Object("false") - to be the exact equivalent of - new String("false") -.
So if your "b is a ... ; not a String or string literal" where taken as
referring to String objects and string primitives then - new
Object("false") - would not be allowed anyway (the resulting value is a
String object).

Ah, that would explain why:
typeof new Object( "foo" );//Object
new Object( "foo" ).constructor // String

What a funny language.

The author of JavaScript himself is not quite happy with the type
distinction between primitive types like boolean and string, and object
types like Boolean and String:

http://weblogs.mozillazine.org/roadm...05/11/js2.html

That's a lot to take in.

It appears that unboxing has been implemented in ES4.

Here's a console printout from ES4:

>var b=new Boolean(false);
if( b ) print(b);
if( !b ) print(b);

false

>>

So it's new behavior, but I think it's a good thing; the current
behavior in es3 is misleading to developers.

Garrett

PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16

[Zeroglif]

Thanks Richard, that was really interesting. Any plans for new test?