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:

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 FunctionDeclara tion: it is still FunctionExpress ion. 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.javas cript 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 FunctionDeclara tion;

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

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>Untitl ed 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************ **********@h54g 2000cwb.googleg roups.com>, VK
<sc**********@y ahoo.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 FunctionDeclara tion; 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.javas cript 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 FunctionDeclara tion; 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.