JavaScript knowledge test

[dhtmlkitchen]

I'll have to think about this one for a moment.




p = 0;
q = null;

That is interesting. Can you explain?

I was going for the valueOf();

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

or
p= new Date(0);
q= new Date(0);
The objects are not equal.

I should have asked (and the above answer can be achieved with the
following code)

How can this be true?
p <= q; //true.
p == q; //false.
p >= q; //true.


What is the output of the following:
var x =
[
{
valueOf:function(){ return 1; }
,toString:function(){ return "one";}

}
,{
valueOf:function(){ return 1; }
,toString:function(){ return "uno";}
}
,{
valueOf:function(){ return 2; }
,toString:function(){ return "manana";}
};
].sort();

print(x);

 

[David Mark]

That is interesting. Can you explain?

According to 11.8.5 (abstract relational comparison algorithm), p and
q are both converted to 0. Clearly 0 is not less than 0.

11.8.5 applies again. 0 is equal to 0.

Unlike the first two, this one is covered in 11.9.3 (abstract equality
comparison algorithm), which is a different animal. It falls all the
way through to the end and returns false.

[snip]


What is the output of the following:
var x =
[
{
valueOf:function(){ return 1; }
,toString:function(){ return "one";}

}
,{
valueOf:function(){ return 1; }
,toString:function(){ return "uno";}
}
,{
valueOf:function(){ return 2; }
,toString:function(){ return "manana";}
};

Typo here.

].sort();

print(x);

In a browser? Nothing. But fix the typo and it will open the print
dialog.

 

[Thomas 'PointedEars' Lahn]

[Function.prototype.x = 0;]

Don't 1 and 3 violate the instruction not to use the Function
constructor. I am not sure if what you did constitutes "use" or not.

This is an interesting point.

ECMA-262 15.3.2

"When |Function| is called as part of a |new| expression, it is a
constructor."

That is not the definition of a constructor in ECMAScript, as you can
read in one of the previous chapters of ECMA-262. So yes, the
instruction was violated.


PointedEars

 

[Peter Michaux]

On Aug 1, 7:35 pm, (e-mail address removed) wrote:
[Function.prototype.x = 0;]
Don't 1 and 3 violate the instruction not to use the Function
constructor. I am not sure if what you did constitutes "use" or not.

This is an interesting point.

ECMA-262 15.3.2

"When |Function| is called as part of a |new| expression, it is a
constructor."

That is not the definition of a constructor in ECMAScript, as you can
read in one of the previous chapters of ECMA-262. So yes, the
instruction was violated.

True the definition of "constructor" in 4.3.4 indicates the
instruction was violated; however, this definition is not consistent
with the usage of the term "constructor" in the document. There are
several places where calling the |Function| object "as a constructor"
appears and implies the |Function| object is not always a constructor.

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

When a |Function| object is called with |new|, is it the |Function|
object that creates the object that is then bound to |this| during the
execution of the function?

If the definition is correct then a function in a third-party library
cannot be termed a constructor or not by looking at the third-party
library alone. It would be necessary to look at the code using the
library to see if the function is every called with |new|.

Peter

 

[dhtmlkitchen]

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

[snip]

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?

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

Garrett

 

[David Mark]

No,

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

I don't see how either of those will work as answers for your first
question.

 

[Henry]

On Aug 2, 4:11 am, Thomas 'PointedEars' Lahn wrote:

True the definition of "constructor" in 4.3.4 indicates the
instruction was violated; however, this definition is not
consistent with the usage of the term "constructor" in the
document. There are several places where calling the
|Function| object "as a constructor" appears and implies
the |Function| object is not always a constructor.

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.

When a |Function| object is called with |new|, is it the |Function|
object that creates the object that is then bound to |this| during
the execution of the function?

It is the function's [[Construct]] method that has the object created.

If the definition is correct then a function in a third-party
library cannot be termed a constructor

<snip>

Yes it could, they all could, but it would probably would not be a
good idea to attach the label to any that were not intended to be use
with the - new - operator.

 

[Thomas 'PointedEars' Lahn]

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.


PointedEars

 

[Peter Michaux]

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]

Peter Michaux wrote:

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

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]

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

But function objects do create object, if you use them as the operand
for - new -.

I think the "creates" in the definition means that the
function is called with |new| at least once.

Wouldn't that become "has created"?

But take it however you like; all functions are constructors or no
functions are constructors, it remains the case that the heading for
section 15.3.2 reads "The Function Constructor", so there is a
'something' to which the specification attaches that label, and whether
the label is appropriate or not we all know what that 'something' is and
so can draw specific meaning from the term "the Function constructor".

Now I can understand quibbling about what constitutes a 'use' of the
Function constructor. For example, if you enumerated the properties of
the global object and acted upon the prototype of the first that was -
typeof - 'function' and had a name that began with 'F', would that be a
use of the function constructor? I would say yes, but the code would not
contain any - Function - identifier.

Richard.

 

[Richard Cornford]

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.

 

[Peter Michaux]

But function objects do create object, if you use them as the operand
for - new -.


Wouldn't that become "has created"?

If "has created" is the criterion, then in the following code |foo| is
not a constructor because this code has never been run.

function Foo(){}
var f = new Foo();

The phrase could be modified to be "after program execution has
created" or "during program execution does create". This would have to
be shored up for situations where "new Foo()" is written but never
executed.

But take it however you like; all functions are constructors or no
functions are constructors,

or the ones that are called with |new| are constructors and the others
aren't.

it remains the case that the heading for
section 15.3.2 reads "The Function Constructor", so there is a
'something' to which the specification attaches that label, and whether
the label is appropriate or not we all know what that 'something' is and
so can draw specific meaning from the term "the Function constructor".
agreed

Now I can understand quibbling about what constitutes a 'use' of the
Function constructor. For example, if you enumerated the properties of
the global object and acted upon the prototype of the first that was -
typeof - 'function' and had a name that began with 'F', would that be a
use of the function constructor? I would say yes, but the code would not
contain any - Function - identifier.

If writing Function.prototpye constitutes using the the "Function
constructor" then I would definitely agree with your yes.

Interesting stuff. I like the hand/fist analogy that a function is
only a constructor when called with "new". We don't need "constructor"
to be a synonym for "function". We already have "function" for that.

I suppose the folks that write ECMAScript specification didn't have
the centuries of work upon which the authors of Webster's Dictionary
could build (and people find problems with dictionary definitions all
the time anyway.)

Peter

 

[Richard Cornford]

On Jul 31, 4:43 pm, Richard Cornford wrote:
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 ;-)

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?

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

 

[Richard Cornford]

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]

On Aug 2, 12:49 pm, Richard Cornford wrote:

Interesting stuff. I like the hand/fist analogy that a
function is only a constructor when called with "new". We
don't need "constructor" to be a synonym for "function".
We already have "function" for that.

From a conceptual point of view, paralleling class-based usage, the most
productive criteria for using the term 'constructor' is to apply it to
functions that are designed to be used to create instances (one or more)
of object with class-like similarities (what would be instances of a
class in a language that had more than one class of object).



The specification's definition is not helpful in practice because I
would argue that it includes almost all functions (is determined by an
object's having a [[construct]] method), and you argue that it would
depend on actual usage and so while unused no functions are
constructors. In either case 'function' is sufficient to state what the
object is, and the specification is precise about the behaviour so the
label is of nominal importance.

I suppose the folks that write ECMAScript specification didn't
have the centuries of work upon which the authors of Webster's
Dictionary could build (and people find problems with dictionary
definitions all the time anyway.)

The document may have benefited from the interest of a pedantic and
hyper-critical editor. Though given the delay experienced in the
proposed release of the 4th edition maybe it was better that the got
something implementable out of the door rather than enlessly argue about
the details.

Richard.

 

[dhtmlkitchen]

^
Why would that be an answer at all?


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


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.

 

[dhtmlkitchen]

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

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.

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

(e-mail address removed) wrote:

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]

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/roadmap/archives/2005/11/js2.html


PointedEars