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.t oString().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.protot ype.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

[Douglas Crockford]

VK wrote:

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

That is a perfectly valid syntax: but useless program-wise.
FunctionDeclara tion 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 FunctionDeclara tion: it is still FunctionExpress ion. 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 FunctionDeclara tion:

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

it is still FunctionExpress ion.

Being a function expression does not make it "perfectly valid syntax".
Expressions are not the units of a javascript program; they are
FunctionDeclara tions and Statements. We have ruled out
FunctionDeclara tions and the only form of statements that can be
constructed from a single Expression are ExpressionState ments, where an
Expression statement is _explicitly_ forbidden from commencing with the
- function - keyword. Thus an ExpressionState ment 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>Untitl ed 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>Untitl ed Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=UTF-8">
<script type="text/javascript">
try {
eval(function() {});

<snip>

A FunctionExpress ion 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>Untitl ed 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>Untitl ed 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 "theoretica l 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 FunctionDeclara tion; 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.