An object's constructor name as a string. Can definitely be determined?

[Peter Michaux]

Hi,

I want to know the name of an object's constructor function as a
string. Something like this

<script type="text/javascript">
function Foo(){};
var a = new Foo();
alert('"' +
a.constructor.toString().match(/function\s*([a-zA-Z\$][\w\$]+)[^\w\$]/)[1]
+ '"');
</script>

Although this works in IE, Opera, Firefox, Safari I'm not sure that it
is guaranteed to work.

I looked in the ECMA-262 specs about the returned string for
Function.prototype.toString() in section 15.2.4.2. It says that the
whitespace, line terminators and semi-colon use are implementation
dependent. I think the above regular expression can handle those
difference.

What I'm worried about is that he specs say the return value has the
form of a "function declaration". Does that mean the returned string
will definitely contain the name of the constructor function? Could it
instead return something like just "function () {}"?

Thank you,
Peter

[RobG]

Peter Michaux wrote:

Hi,

I want to know the name of an object's constructor function as a
string. Something like this

<script type="text/javascript">
function Foo(){};
var a = new Foo();
alert('"' +
a.constructor.toString().match(/function\s*([a-zA-Z\$][\w\$]+)[^\w\$]/)[1]
+ '"');
</script>

[...]

What I'm worried about is that he specs say the return value has the
form of a "function declaration". Does that mean the returned string
will definitely contain the name of the constructor function? Could it
instead return something like just "function () {}"?

A quick test shows that you can use an anonymous function as a
constructor, and it is returned in the form of a function declaration,
but it's actually a statement:

var nameObj = function(name){
this.name = name;
this.showName = function(){alert(this.name);}
}

var x = new nameObj('Peter');
x.showName();
alert(x.constructor);

shows:

function (name) { ...}

which only makes sense as a function statement. I guess you could say
it's in the form of a declaration because the left hand side is
missing. Of course you might fix that with:

var nameObj = function nameObj (name){ ... }

But that may not be helpful. In some browsers the constructor object
has a name property, but not all unfortunately. Can I be of any less
help? :-)
--
Rob

[Douglas Crockford]

Peter Michaux wrote:

Hi,

I want to know the name of an object's constructor function as a
string. Something like this

<script type="text/javascript">
function Foo(){};
var a = new Foo();
alert('"' +
a.constructor.toString().match(/function\s*([a-zA-Z\$][\w\$]+)[^\w\$]/)[1]
+ '"');
</script>

Although this works in IE, Opera, Firefox, Safari I'm not sure that it
is guaranteed to work.

No, it's not. I don't like object models where it is necessary to query
instances about their types. But if you feel you must, make it reliable. The
constructor property is not reliable because it is lost in the simple
inheritance pattern:

function Bar(){}
Bar.prototype = new Foo();

var b = new Bar();
alert(b.constructor === Bar); // produces false

So be explicit in identifying your type names.

Foo.prototype.type = 'Foo';
Bar.prototype.type = 'Bar';

alert(a.type);
alert(b.type);

http://javascript.crockford.com/

[Peter Michaux]

RobG wrote:

Peter Michaux wrote:

Hi,

I want to know the name of an object's constructor function as a
string. Something like this

<script type="text/javascript">
function Foo(){};
var a = new Foo();
alert('"' +
a.constructor.toString().match(/function\s*([a-zA-Z\$][\w\$]+)[^\w\$]/)[1]
+ '"');
</script>

[...]

What I'm worried about is that he specs say the return value has the
form of a "function declaration". Does that mean the returned string
will definitely contain the name of the constructor function? Could it
instead return something like just "function () {}"?

A quick test shows that you can use an anonymous function as a
constructor, and it is returned in the form of a function declaration,
but it's actually a statement:

var nameObj = function(name){
this.name = name;
this.showName = function(){alert(this.name);}
}

var x = new nameObj('Peter');
x.showName();
alert(x.constructor);

shows:

function (name) { ...}

which only makes sense as a function statement. I guess you could say
it's in the form of a declaration because the left hand side is
missing. Of course you might fix that with:

var nameObj = function nameObj (name){ ... }

But that may not be helpful. In some browsers the constructor object
has a name property, but not all unfortunately. Can I be of any less
help? :-)

Hi Rob,

I tested the things you mentioned also. It seems the the return value
of toString() can take the form of a function statement when the
function is anonymous. So does this mean the ECMA specs are a little
bit wrong? If a function is anonymous, there is no way that toString
will be able to return a function declaration since the identifier is
not available.

Thanks,
Peter

[VK]

Peter Michaux wrote:

It seems the the return value
of toString() can take the form of a function statement when the
function is anonymous. So does this mean the ECMA specs are a little
bit wrong? If a function is anonymous, there is no way that toString
will be able to return a function declaration since the identifier is
not available.

That was already explained at
<http://groups.google.com/group/comp.lang.javascript/msg/81452faadf0019d1>
- please read it carefully.

This way it shouldn't surprise you any more than
function foo() {}
var bar = foo;
alert(bar.toString()) // that the name will be? foo of course

ECMAScript specs are not exactly wrong, but they are very confusingly
written: so confusingly actually that professional C++ programmers did
not get it right in application to this matter and they had to say
sorry latter (JScript team) though sorry should be ECMA's free-lancers.

In application to your routine two more issues has to be taken into
consideration:

1) var foo = function(){} creates anonymous function with toString
method returning "function(){..."
At the same time anonymous functions in event handlers (like one in
<body onload="") has toString method returning "function anonymous()
{...". The same is for function created by using Function()
constructor. It has nothing to do with some pragrammatical differences,
it was just preserved this way for legacy reasons. Brendan Eich once
had to explain it and say sorry on bugzilla.mozilla.org, later I'll
find the link again.
In any case you have to adjust the neuristic for both possible values
for anonymous functions.

2) toString method can be overloaded to prevent source code dump or to
be used for something completely else. It is rather easy fixable as
well but in such case it looks more like a reverse engineering so I
will not advise: but only point onto such possibility.

[RobG]

Peter Michaux wrote:

RobG wrote:

Peter Michaux wrote:

[...]

What I'm worried about is that he specs say the return value has the
form of a "function declaration". Does that mean the returned string
will definitely contain the name of the constructor function? Could it
instead return something like just "function () {}"?

A quick test shows that you can use an anonymous function as a
constructor, and it is returned in the form of a function declaration,
but it's actually a statement:

[...]

I tested the things you mentioned also. It seems the the return value
of toString() can take the form of a function statement when the
function is anonymous. So does this mean the ECMA specs are a little
bit wrong? If a function is anonymous, there is no way that toString
will be able to return a function declaration since the identifier is
not available.

I don't think the specification is wrong or contradictory, the wording
is:

"15.3.4.2 Function.prototype.toString ( )
"An implementation-dependent representation of the function is
returned. This representation has the syntax of a
FunctionDeclaration. Note in particular that the use and placement
of white space, line terminators, and semicolons within the
representation string is implementation-dependent."

The important part is "has the syntax of", it doesn't say "it is" a
function declaration. It is similar to the confusion caused by the
occasional use of "undefined" when "not defined" is meant.

The function is returned in a format that looks like a function
declaration, but since it's anonymous, there is no identifier or name.
The only solution to me is to put an identifier into function
statements, but that will only suit code you can control, not a general
case.

This may be an interesting exercise but using the constructor property
as the basis for program logic is unlikely to be reliable. Try
Douglas' suggestion: give your native function objects an explicit type
parameter.
--
Rob

[Michael Winter]

Peter Michaux wrote:

It seems the the return value of toString() can take the form of a
function statement when the function is anonymous. ...

That is precisely the form it /should/ take.

If a function is anonymous, there is no way that toString will be
able to return a function declaration since the identifier is not
available.

You seem to be overlooking the rather important initial sentence:

An implementation-dependent representation of the function is
returned.

An implementation is free to use whatever identifier it likes. An
obvious choice is "anonymous", though anything (including a
randomly-generated identifier) will do.

Mike

[Peter Michaux]

RobG wrote:
<snip>

I don't think the specification is wrong or contradictory, the wording
is:

"15.3.4.2 Function.prototype.toString ( )
"An implementation-dependent representation of the function is
returned. This representation has the syntax of a
FunctionDeclaration. Note in particular that the use and placement
of white space, line terminators, and semicolons within the
representation string is implementation-dependent."

The important part is "has the syntax of", it doesn't say "it is" a
function declaration. It is similar to the confusion caused by the
occasional use of "undefined" when "not defined" is meant.

The function is returned in a format that looks like a function
declaration, but since it's anonymous, there is no identifier or name.
The only solution to me is to put an identifier into function
statements, but that will only suit code you can control, not a general
case.

At the beginning of section 13 of the specs it says

Syntax

FunctionDeclaration:
function Identifier (FormalParameterList_opt) { FunctionBody }

FunctionExpression:
function Identifier_opt (FormalParameterList_opt) {FunctionBody}

Does the following sound reasonable? In the FunctionDeclaration the
Identifier is not optional so a function declaration cannot be
anonymous. An anonymous function is always introduced through a
FunctionExpresssion.

Perhaps the section about toString() for a function should say that the
returned value has the syntax of a FunctionExpression. This would
account for anonymous functions.

This may be an interesting exercise

I think that is all it has become now.

but using the constructor property
as the basis for program logic is unlikely to be reliable.

Try Douglas' suggestion: give your native function objects an explicit type
parameter.

I think this is good advice.

Thanks Rob and Douglas.

Peter

[VK]

FunctionDeclaration:

function Identifier (FormalParameterList_opt) { FunctionBody }

FunctionExpression:
function Identifier_opt (FormalParameterList_opt) {FunctionBody}

Does the following sound reasonable? In the FunctionDeclaration the
Identifier is not optional so a function declaration cannot be
anonymous. An anonymous function is always introduced through a
FunctionExpresssion.

Did you try?
<script type="text/javascript">
function() {}
</script>

That is a perfectly valid syntax: but useless program-wise.
FunctionDeclaration is not evaluated, so there is no "hook" left to use
this function in your program. This is all what they tried (but failed)
to say.

Perhaps the section about toString() for a function should say that the
returned value has the syntax of a FunctionExpression. This would
account for anonymous functions.

They couldn't say it in 1999, because already there was a great amount
of scripts using toString value from anonymous functions defined for
intrinsic handlers (see again my other post in this thread). I do agree
in advance that the chosen form for them:
"function anonymous() {..." is sub-optimal and semi-contadictory (if
function is called "anonymous" then it is called somehow and so it is
not anonymous). More logical would be do not use the word "anonymous"
at all as in the latter practice or at least use another order:
"anonymous function(){..."

But whatever was done - it was done, and we have to deal now with the
legacy outcomes.

[Richard Cornford]

VK wrote:
<snip>

Did you try?
<script type="text/javascript">
function() {}
</script>

That is a perfectly valid syntax:

No it is not. No ExpressionStatement may commence with the 'function'
keyword and the Identifier in a Function Declaration is not optional.

but useless program-wise. FunctionDeclaration is not evaluated,
so there is no "hook" left to use this function in your program.
This is all what they tried (but failed) to say.

<snip>

Who are these "they" and why are they trying to be so incoherent?

Richard.

[Douglas Crockford]

VK wrote:

Did you try?
<script type="text/javascript">
function() {}
</script>

That is a perfectly valid syntax: but useless program-wise.
FunctionDeclaration is not evaluated, so there is no "hook" left to use
this function in your program. This is all what they tried (but failed)
to say.

JSLint reports:

Missing name in function statement.

http://www.JSLint.com/

[VK]

Douglas Crockford wrote:

Did you try?
<script type="text/javascript">
function() {}
</script>

JSLint reports:

Missing name in function statement.

http://www.JSLint.com/

JSLint is not the script engine, so it's allowed to have different
opinions on different topics ;-)

But I have to reconsider my previous statement:
<script type="text/javascript">
function() {}
</script>
is not a FunctionDeclaration: it is still FunctionExpression. Here we
have "expression without assignment" wich is totally valid byt rather
useless. Functionally it is the same as
<script type="text/javascript">
4;
</script>
or
<script type="text/javascript">
"foobar";
</script>

[Richard Cornford]

VK wrote:

Douglas Crockford wrote:

>VK wrote:

>>Did you try?
<script type="text/javascript">
function() {}
</script>

That is a perfectly valid syntax:

JSLint reports:

Missing name in function statement.

http://www.JSLint.com/

JSLint is not the script engine, so it's allowed to have different
opinions on different topics ;-)

But I have to reconsider my previous statement:

It was a false statement.

<script type="text/javascript">
function() {}
</script>
is not a FunctionDeclaration:

Could not be a FunctionDeclaration because it has no Identifier and the
Identifier is not optional in a FunctionDeclaration.

it is still FunctionExpression.

Being a function expression does not make it "perfectly valid syntax".
Expressions are not the units of a javascript program; they are
FunctionDeclarations and Statements. We have ruled out
FunctionDeclarations and the only form of statements that can be
constructed from a single Expression are ExpressionStatements, where an
Expression statement is _explicitly_ forbidden from commencing with the
- function - keyword. Thus an ExpressionStatement consisting of only a
Function Expression is not "perfectly valid syntax".

I told you this yesterday, but instead of verifying that I was correct
here you are trying to defend another of your false statements. If you
don't know what constitutes syntactically correct javascript (and you
have made it completely clear over the years that you don't, and are
not capable of learning it) it would be better to keep quiet on the
subject.

Here we have "expression without assignment" wich is totally valid

It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

byt rather useless. Functionally it is the same as
<script type="text/javascript">
4;
</script>
or
<script type="text/javascript">
"foobar";
</script>

Except that neither of those are syntax errors, and so may appear in
javascript source code without risking it not being interpretable.

Richard.

[VK]

Richard Cornford wrote:

It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

byt rather useless. Functionally it is the same as
<script type="text/javascript">
4;
</script>
or
<script type="text/javascript">
"foobar";
</script>

Except that neither of those are syntax errors, and so may appear in
javascript source code without risking it not being interpretable.

Any ECMAScript-compliant engine erroring out on the below, please.

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<script type="text/javascript">
try {
eval(function(){});
}
catch(e) {
window.alert(e.message);
}

</script>
</head>

<body>

</body>
</html>

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>VK wrote:

>>>VK wrote:
Did you try?
<script type="text/javascript">
function() {}
</script>
That is a perfectly valid syntax:

<snip>

>>Here we have "expression without assignment" wich is totally valid

<snip>

>It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

<snip>

Any ECMAScript-compliant engine erroring out on the below, please.

You are a halfwit. In what sense does the code below relate to anything
that has come before?

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<script type="text/javascript">
try {
eval(function(){});

<snip>

A FunctionExpression is a completely valid argument to a function call,
and the - eval - function does not do anything with non-string
arguments but return them. There is no syntax error here, and so its
not erorring is unsurprising.

It is telling of your actual understanding of this subject that you
make false statements and then when you are corrected start posting
code that you are incapable of seeing as having no relevance to the
question in hand. I suppose here we are suffering again form you not
actually knowing what the code you write is supposed to do, and so
thinking this to relevant when it is not.

Richard.

[VK]

Richard Cornford wrote:

It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

byt rather useless. Functionally it is the same as
<script type="text/javascript">
4;
</script>
or
<script type="text/javascript">
"foobar";
</script>

Except that neither of those are syntax errors, and so may appear in
javascript source code without risking it not being interpretable.

Any ECMAScript-compliant engine erroring out on the below, please.

<html>
<head>
<title>Untitled Document</title>
<script type="text/javascript">
function(){}
</script>
</head>
<body>
</body>
</html>

P.S. eval in the previous sample was used to wrap possible syntax
errors so make them catchable at run-time. It is useless in this case
(because there are no syntax errors to expect), just an automated
doing: "error", "syntax" keywords triggered the corresponding style in
my head :-)

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>VK wrote:

>>>VK wrote:
Did you try?
<script type="text/javascript">
function() {}
</script>
That is a perfectly valid syntax:

<snip>

>>Here we have "expression without assignment" wich is totally valid

<snip>

>It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

<snip>

>It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

<snip>

Any ECMAScript-compliant engine erroring out on the below, please.

You mean like Opera 9 reporting a syntax error?

<html>
<head>
<title>Untitled Document</title>
<script type="text/javascript">
function(){}
</script>
</head>
<body>
</body>
</html>

P.S. eval in the previous sample was used to wrap possible syntax
errors

Whatever you may have thought you were using it for the - eval -
function only executes code if its argument is a string, so passing it
a function object guaranteed that it did nothing.

so make them catchable at run-time.

And that is what would have happened, if the argument had been a
string.

It is useless in this case
(because there are no syntax errors to expect),

Not true, If the argument had been the string "function(){};" then the
syntax error would have happened. But achieving that pre-supposes some
sort of knowledge of how javascript works, so you just posted nonsense
instead.

just an automated doing: "error", "syntax" keywords triggered the
corresponding style in my head :-)

Gibberish.

Richard.

[VK]

Richard Cornford wrote:

VK wrote:

Richard Cornford wrote:

VK wrote:
VK wrote:
Did you try?
<script type="text/javascript">
function() {}
</script>
That is a perfectly valid syntax:

<snip>

>Here we have "expression without assignment" wich is totally valid

<snip>

It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

<snip>

It is a syntax error. It was a syntax error yesterday and will still be
a syntax error tomorrow.

<snip>

Any ECMAScript-compliant engine erroring out on the below, please.

You mean like Opera 9 reporting a syntax error?

Yep... Opera 9 errors out. That proves again the old "Web axiom" that
for any feature will be at least one UA that will get it wrong.

Lucky this "feature" has only theoretical interest.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

<snip>

>>Any ECMAScript-compliant engine erroring out on the below, please.

You mean like Opera 9 reporting a syntax error?

Yep... Opera 9 errors out. That proves again the old "Web axiom" that
for any feature will be at least one UA that will get it wrong.

In what sense is reporting a syntax error when code contains a syntax
error getting it wrong? It might be better argued that browsers
tolerating what should be syntax errors are 'getting it wrong', though
browsers being tolerant in the face of incompetent web developers is
hardly a new phenomenon.

Your "web axiom" is typically worthless. A much more useful, and
applicable axiom is; "be liberal in what you accept and strict in what
you send". with being liberal in what they accept being what some
browsers do in tolerating a syntax errors in javascript source code,
and being strict in what you send meaning that you write syntactically
correct code to be sent to the browser in the first place. After all,
has anyone observed any browser ever having a problem with receiving
syntactically correct javascript source code?

Lucky this "feature" has only theoretical interest.

Maybe only "theoretical interest" for you, as you will never know
enough to distinguish between correct syntax and incorrect. But while
you treat browsers that do not understand the 'code' you write as not
being supportable others write code that works fine with them (even
genuinely cross-browser). Could it be that the browsers you deprecate
so much are actually just not tolerating the code you are sending them
because not knowing what is syntactically correct in javascript you are
sending them syntax errors that you cannot recognise. Wouldn't that
leave knowing syntactic correctness having a very practical impact on
the ability to surpass your 'skills' and so write genuinely
cross-browser code?

Richard.

[VK]

Richard Cornford wrote:

"be liberal in what you accept and strict in what
you send".

Exactly: and this rule (which is especially true for javascript
engines) is violated on Opera 9. The rule is that a javascript program
may error out only if no available interpretations left: this is why
even utterly wrong scripts are "working" sometimes - but often not in
the intended way.

The exact parsing algorithm was given by you in this thread, as well
as two possible branches of this algorithm.

<script type="text/javascript">
function(){}
</script>

1) Found "function" keyword left hand side, searching for identifier.
2) If an identifier found then this is FunctionDeclaration; if not then
go to step 3
3) No identifier found, left hand side anonymous function. If Opera 9
then go to step 4, otherwise go to step 5
4) Opera 9: "booh, booh... bad syntax... :-("
4) Others: function expression w/o assignment, seems useless but not
our damn business.

This way Opera 9 between i)trying to further interpret the code and ii)
error out is choosing to error out, which is not OK for a reliable
script engine.

[Douglas Crockford]

VK wrote:

Douglas Crockford wrote:

>>Did you try?
<script type="text/javascript">
function() {}
</script>

>JSLint reports:

Missing name in function statement.

http://www.JSLint.com/

JSLint is not the script engine, so it's allowed to have different
opinions on different topics ;-)

That is true, but it is irrelevant. If you ran all of your snippets thru JSLint
before posting to this forum, your reputation would be significantly less tarnished.

But I have to reconsider my previous statement:
<script type="text/javascript">
function() {}
</script>
is not a FunctionDeclaration: it is still FunctionExpression. Here we
have "expression without assignment" wich is totally valid byt rather
useless.

It is a syntax error. Your example isn't just useless. It is wrong.

[Michael Winter]

VK wrote:

Richard Cornford wrote:

>"be liberal in what you accept and strict in what you send".

Exactly: and this rule (which is especially true for javascript
engines) is violated on Opera 9.

It is a principle, not a rule. That said, it's not one that I would want
to apply to a programming or scripting language.

The rule is that a javascript program may error out only if no
available interpretations left: this is why even utterly wrong
scripts are "working" sometimes - but often not in the intended way.

Which is precisely why I'd prefer it not happen with programming
languages. Better to have a program (or better yet, a compiler, where
applicable) raise an exception and stop executing than guessing and
acting unpredictably.

[snip]

Mike

[Randy Webb]

VK said the following on 11/8/2006 9:03 AM:

Richard Cornford wrote:

>"be liberal in what you accept and strict in what
you send".

Exactly: and this rule (which is especially true for javascript
engines) is violated on Opera 9.

You really are an idiot.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>"be liberal in what you accept and strict in what
you send".

Exactly: and this rule (which is especially true for javascript
engines) is violated on Opera 9.

It all goes straight over your head, doesn't it? You have complete
control over the code you write, but you would rather blame a web
browser for doing no more than it claims to do than learn how to take
control of the code you write.

The rule is that a javascript program
may error out only if no available interpretations left: this is why
even utterly wrong scripts are "working" sometimes -

Finally a subject where you have some experience.

but often not in the intended way.

The exact parsing algorithm was given by you in this thread,

No it was not.

as well as two possible branches of this algorithm.

I certainly mentioned that the only two applicable target constructs
were either Statements or Function Declarations.

<script type="text/javascript">
function(){}
</script>

1) Found "function" keyword left hand side, searching for identifier.

There is no sense in "left hand side". the keyword would be the next
token in a sequence where all preceding tokens (if any) were accounted
for.

2) If an identifier found then this is FunctionDeclaration;

It is not a FunctionDeclaration unless it fully satisfies the
production rules for FunctionDeclaration.

if not then go to step 3
3) No identifier found, left hand side anonymous function.

Anonymous functions don't have sides. And is Function Declaration is
excluded the target construct is now Statement.

If Opera 9
then go to step 4, otherwise go to step 5
4) Opera 9: "booh, booh... bad syntax... :-("

Or, you now know you have messed up and can do something about fixing
your code.

(Also, you are assuming that Opera 9 is the only browser that will
apply the syntax rules in accordance with the specification. It almost
certainly is not, and indeed it would be more rational to assume that
all browsers would apply the language's syntax rules and then be
surprised at the few that are tolerant of this type of error).

4) Others: function expression w/o assignment, seems useless
but not our damn business.

And now you have someone who thinks that what they have done is
correct, and will probably be going on to repeat their mistake on the
grounds that it "works", even though it is then no more than a mystical
incantation repeated because it has been used in code that "works" in
the past and has not directly caused problems (at least under
superficial testing).

I don't need to tell you anything about programming by mystical
incantation, or superficial testing, as you are certainly the expert in
those areas.

This way Opera 9 between i)trying to further interpret the code and ii)
error out is choosing to error out, which is not OK for a reliable
script engine.

It is that sort of thinking that results in the code you write, which
is anything but reliable.

Richard.

[VK]

Hah! The entire Co in one spot (though the posting order hierarchy is
not correct IMHO. Richard?)

OK, so much easy to answer:

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">

function(){} + 2 == 'Learn JavaScript better, guys';

// And do not take single erroneus implementation
// for some standard.
</script>
</head>
<body>
</body>
</html>

P.S. Damn German beer is good! I'm getting sad just thinking of coming
back to Bud-water in a few weeks. :-(
:-)

[Richard Cornford]

VK wrote:
<snip>

OK, so much easy to answer:

<snip>

function(){} + 2 == 'Learn JavaScript better, guys';

Another syntax error and another pointless operation (if it were not a
syntax error). So what is your point?

// And do not take single erroneus implementation
// for some standard.

<snip>

Who said Opera was the only browser reporting the syntax error? Your
question was whether there were any browsers which had a problem with
your syntax error, and if one can be named that question has been
answered. There is no need for any single browser to be taken as
defining a standard when a standard already exists and is unambiguous
on the subject.

Richard.

[VK]

Richard Cornford wrote:

Who said Opera was the only browser reporting the syntax error?

Do you have any other one besides Opera 9? I have no idea about Safari,
but I would like to dismiss it right away (in case if): if you take a
dring every time this UA does something right with scripting, you'll
end up thirsty and angry :-)

Any other mainstream browser?

A good hint: if you're in dubts about something, check it on Netscape
4.7 In 99% of cases whatever it does is what was really intended, if it
contradicts to ECMAScript specs it simply means that the free-lancers
failed to describe properly what they've seen.

One more time: there is not syntax error here, but there is Opera's
parser laziness: instead of further interprete the source and to
understand that this is an expression w/o assignment: instead of that
it just errors out on the first opportunity.

[Peter Michaux]

Richard Cornford wrote:

VK wrote:

<snip>

Richard, you really are generous. Most would have given up long ago.

Peter

[John G Harris]

In article <11**********************@h54g2000cwb.googlegroups .com>, VK
<sc**********@yahoo.comwrites

<snip>

><script type="text/javascript">
function(){}
</script>

1) Found "function" keyword left hand side, searching for identifier.
2) If an identifier found then this is FunctionDeclaration; if not then
go to step 3
3) No identifier found, left hand side anonymous function.

<snip>

Obviously the programmer has forgotten to type something like
this.a =
at the beginning of the line, or has forgotten to type the function name
in the middle of the line. A halfway decent compiler will say
!!!ERROR!!!
so the programmer sees and corrects the mistake straight away.

If the compiler says nothing the programmer has to write to
comp.lang.javascript saying it doesn't work, then spend hours
complaining that no-one has replied quickly enough, and then complain
again when they ask to see more code because he thinks the error is
somewhere else, which it isn't.

Unfortunately, some people get paid for the time needed to find obscure
errors in their code. They get paid less if the error is made too
obvious, so they scream loudly when the error is highlighted straight
away.

John
--
John Harris

[VK]

1) Found "function" keyword left hand side, searching for identifier.

2) If an identifier found then this is FunctionDeclaration; if not then
go to step 3
3) No identifier found, left hand side anonymous function.

<snip>

Obviously the programmer has forgotten to type something like
this.a =
at the beginning of the line, or has forgotten to type the function name
in the middle of the line. A halfway decent compiler will say
!!!ERROR!!!
so the programmer sees and corrects the mistake straight away.

Obviously I will never hire you for an application development :-(
because you have a holy mix of that a parser/engine is and what a
tidy-like suggestive checker is.

The engine's job is not to enforce some "preferred style" of
programming or some "best practice" onto developers. It has much more
humble but much more technically difficult task: from each segment of
the source code try to produce an execution code non-violating given
border criterias. That is not damn parser business what is this code
for and why did one use it this way.
Tidy-like checkers are free to declare ++i or --i harmful or declare
void function(){};
as an error (an opinion shared by no one real engine). Parser has not
such freedom: it has to eat whatever fed until chokes.

[Richard Cornford]

VK wrote:

Richard Cornford wrote:

>Who said Opera was the only browser reporting the syntax error?

Do you have any other one besides Opera 9?

Yes. Not reporting this syntax error as a syntax error appears to be the
exception (unsurprisingly).

I have no idea about Safari,
but I would like to dismiss it right away

Which brings us back to what I said earlier. You write code without
recognising a syntax error in the language you are using and then when
your scripts only work in a couple of browsers at most you blame the
browsers. That the fault here is yours rather than the browser's is
obvious as soon as you realise that people exist who do manage to write
effective code for Safari. You think they are doing that by putting
disproportionate effort into the task, but it is more likely that they
are just presenting Safari with code devoid of syntax errors, mystical
incantations and your other nonsense, and the result just works.

(in case if): if you take a dring every time this
UA does something right with
scripting, you'll end up thirsty and angry :-)

The VK definition of what is "right" is too detached from reality for
that to be a criteria for judging anything.

Any other mainstream browser?

Earlier today it was "Any ECMAScript-compliant engine erroring out on the
below, please", but now that it should be obvious that
ECMAScript-compliant browsers are likely to generate syntax errors with
code that contains syntax errors you want to retreat to your 'safe'
ground of "mainstream browsers". Which presumably is "mainstream
browsers" as defined by VK, and so pretty much Windows IE and Firefox
only.

A good hint: if you're in dubts about something, check it
on Netscape 4.7

Idiot.

In 99% of cases whatever it does is what was really
intended,

Unlikely as Netscape 4.7 implemented ECMA 262 2nd Edition (with
extensions) and your "mainstream browsers" (and other current scriptable
browsers) implement ECMA 262, 3rd Edition.

if it contradicts to ECMAScript specs it simply means
that the free-lancers

Have you looked at the list of the people who wrote ECMA 262?

failed to describe properly what they've seen.

With the contributors to ECMA 262 having direct access to the source code
for both JavaScript(tm) and JScript it is unlikely that observation
determined their behaviour.

One more time: there is not syntax error here,

Only when "here" is restricted to the contents of your deranged mind.

but there is Opera's parser laziness:

It is not lazy to report a syntax error when one is seen.

instead of further interprete the source and to
understand that this is an expression w/o assignment:

There is nothing in the language's syntax that allows such an
interpretation, and you cannot assume that any browser that does not
report the syntax error is making such an interpretation. As far as you
know they are just recognising the futility of the construct and just
filtering it out. Indeed experimentation suggests that the syntax error
is being filtered out rather than being interpreted as a Function
Expression. Try:-

<html>
<head>
<title></title>
<script type="text/javascript">
var a;

function(){alert('I was recognised 1');}

(a);

var b = function(){alert('I was recognised 2');}

(a);

</script>
</head>
<body>
</body>
</html>

- in Firefox and IE 6 and you see "I was recognised 2" alerted by the
second function expression but no sign of 'I was recognised 1', which
would be the consequences of the - function(){alert('I was recognised
1');} - line being interpreted as a function expression, as can be
illustrated by wrapping that line in parenthesise to give:-

<html>
<head>
<title></title>
<script type="text/javascript">
var a;

(function(){alert('I was recognised 1');})

(a);

var b = function(){alert('I was recognised 2');}

(a);

</script>
</head>
<body>
</body>
</html>

- where the absence of any syntax error allows both 'I was recognised 1'
and 'I was recognised 2' to be alerted.

So " interprete the source and to understand that this is an expression
w/o assignment" is not what Firefox or IE are doing with the syntax
error. Instead they appear to be silently ignoring it. And silently
ignoring syntax errors is less useful than reporting them.

instead of that
it just errors out on the first opportunity.

Which tells the programmer at the earliest point possible that they have
made an error.

Obviously you would not appreciate that, as you don't like being told
that you have made an error, and prefer not to recognise them when you
have. But then that is one of the things makes you by far the worst
programmer I have ever encountered.

Richard.

[John G Harris]

In article <11**********************@m73g2000cwd.googlegroups .com>, VK
<sc**********@yahoo.comwrites

>1) Found "function" keyword left hand side, searching for identifier.
2) If an identifier found then this is FunctionDeclaration; if not then
go to step 3
3) No identifier found, left hand side anonymous function.

<snip>

>Obviously the programmer has forgotten to type something like
this.a =
at the beginning of the line, or has forgotten to type the function name
in the middle of the line. A halfway decent compiler will say
!!!ERROR!!!
so the programmer sees and corrects the mistake straight away.

Obviously I will never hire you for an application development :-(
because you have a holy mix of that a parser/engine is and what a
tidy-like suggestive checker is.

You obviously don't know what a parser does. It's a pattern matcher. A
match tells the compiler which syntax rule the code matches. Then the
compiler knows exactly what the programmer wants the program to do.

For instance, if the parser is given
var x = 42;
the parser finds that the code matches the syntax rule for creating a
variable named x with the initial value 42.

On the other hand, if the parser is given
x var 42 =;
the parser doesn't find a match with any of the hundreds of syntax rules
so the compiler doesn't know what the programmer was thinking.

In VK's universe the browser's AI plugin would come to life at this
point and say that it believes the programmer meant ... well, what?

>The engine's job is not to enforce some "preferred style" of
programming or some "best practice" onto developers. It has much more
humble but much more technically difficult task: from each segment of
the source code try to produce an execution code non-violating given
border criterias. That is not damn parser business what is this code
for and why did one use it this way.
Tidy-like checkers are free to declare ++i or --i harmful or declare
void function(){};
as an error (an opinion shared by no one real engine). Parser has not
such freedom: it has to eat whatever fed until chokes.

VK is confused once again. The parser's job is to see which syntax rule
the code matches. It's a style guide or lint program that's expected to
say it's dangerous to use 'with'. Thus the parser must declare that
; ++i; --i; void function() {};
are all legal since each matches a syntax rule. A style guide might say
that i++ is preferred to ++i, or that void is rarely needed, but it
doesn't have to say that.

Does javascript have syntax rules? Yes : they're written in ECMA 262.
Does every javascript programmer have to be able to read them? No, but
if they can't they mustn't tell people what the rules are or aren't.

John

Postscript :
No syntax rule matches
; function() {};
but there is one that matches
; void function() {};
Strange, but true.
--
John Harris