Why wont this script work?

A

Ali

I have the following web page with a script in it.

<html>

<head>

<title>Make Your Own Objects test</title>

<script>

function info(self,n,e) {

function showInfo(self,nam, ema) {

document.write("<hr>");

document.write("<b>Name: </b>"+nam);

document.write("<b>Email: </b>"+ema);

}

self.name = n;

self.email= e;
self.show() = showInfo(self.name,self.email);

}

</script>

</head>

<body>

<script>

ali = info("Ali","(e-mail address removed)");

zainab = info("Zainab","(e-mail address removed)");


ali.show();
zainab.show();

</script>

</body>

</html>

I want the script to make two objects: ali and zainab. These objects
are to have two properties (name and email) and a method (show). The
show method is supposed to display the other two properties of the
object.

Please Help. Thank You. :)
 
L

Lee

Ali said:
I have the following web page with a script in it.
I want the script to make two objects: ali and zainab. These objects
are to have two properties (name and email) and a method (show). The
show method is supposed to display the other two properties of the
object.

Is this for a class, or are you trying to learn Javascript on your own?
Are you working from some sort of textbook or online tutorial?
 
T

Thomas 'PointedEars' Lahn

Ali said:

The DOCTYPE declaration is missing prior to this start tag, e.g.

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
[...]
<script>
^
The "type" attribute is missing:

function info(self,n,e) {

function showInfo(self,nam, ema) {

Nested functions are not allowed in ECMAScript and implementations.
However, it is supported in JavaScript 1.5. The question probably
answered below is: Why do you consider it necessary here?
document.write("<hr>");

document.write("<b>Name: </b>"+nam);

document.write("<b>Email: </b>"+ema);

}

self.name = n;

`self' refers to the current `window' object as this object is virtually
identical with the global object where the `self' property is available.
Assigning a value to its `name' property may not be possible. Most
certainly you are looking for `this.name'.
self.email= e;
self.show() = showInfo(self.name,self.email);
^^
The call operator may only be used right hand side in JavaScipt,
ECMAScript and its implementations.
}

[...}
<script>

See above.
ali = info("Ali","(e-mail address removed)");
zainab = info("Zainab","(e-mail address removed)");

Variables should be declared, using the `var' keyword:

var ali = ...;
var zainab = ...;

Assuming that "info" is the constructor of an object, the proper syntax is

var ali = new info("Ali", "(e-mail address removed)");
var ali = new info("Zainab","(e-mail address removed)");
ali.show();
zainab.show();>

However, if show() ought to be a method of "info" objects, the proper syntax
is

function info(n, e)
{
this.show = function info_show()
{
// escape ETAGO if used in HTML context
document.write("<hr>"
+ "<b>Name: <\/b>" + this.name
+ "<b>Email: <\/b>" + this.email);
}

// consider ... = x || ""; for a default value
this.name = n;
this.email = e;
}

or better if info_show() does not contain a closure:

function info(n, e)
{
// see above
this.name = n;
this.email = e;
}

info.prototype.show = function info_show()
{
document.write("<hr>"
+ "<b>Name: <\/b>" + this.name
+ "<b>Email: <\/b>" + this.email);
}

However, document.write() is not a proper method to output information
after the document has been loaded. It may add information to the
document temporarily or it may overwrite the entire document, including
the functions defined therein. Ask Google Groups for proper solutions.

To avoid confusion and undesired side effects with built-in properties,
good code style recommends to let constructor identifiers begin with an
uppercase letter:

function Info(...)
{
...
}
[...]
I want the script to make two objects: ali and zainab. These objects
are to have two properties (name and email) and a method (show). The
show method is supposed to display the other two properties of the
object.

And most certainly, you should have added that the properties
of the second object are not displayed (as expected).

"Does not work" is a useless error description. [psf 4.11]

Please read the FAQ before posting.


PointedEars
 
J

John G Harris

Nested functions are not allowed in ECMAScript and implementations.
However, it is supported in JavaScript 1.5.
<snip>

It is allowed in ECMAScript v3, which has been around for over four
years.

John
 
T

Thomas 'PointedEars' Lahn

John said:

Please stop posting attribution novels; the reasons have been explained
(to you) several times before.
It is allowed in ECMAScript v3, which has been around for over four
years.

I'd be happy to be wrong here and read about the required productions
from the ECMAScript 3 grammar in a posting of you.


PointedEars
 
R

Randy Webb

Thomas said:
John G Harris wrote:




Please stop posting attribution novels; the reasons have been explained
(to you) several times before.

Considering that you are the only one that explains it, and you
generally and 100% explain it wrongly, thats just more of your unfounded
garbage spouting.
 
M

Michael Winter

John said:
[snip]
It is allowed in ECMAScript v3, which has been around for over four
years.

I'd be happy to be wrong here and read about the required productions
from the ECMAScript 3 grammar in a posting of you.

Will I do?

Unless I'm missing something major (quite possible as I don't have this
thread in full), you seem to be suggesting that

function a() {
function b() {
}
}

is illegal. Is that correct? Well, in a code example, section 13.2 -
Creating Function Objects, they have written almost precisely the above.

If you want the associated grammar:

FunctionDeclaration :
function Identifier ( FormalParameterListopt ) { FunctionBody }

FunctionBody :
SourceElements

SourceElements :
SourceElement
SourceElements SourceElement

SourceElement :
Statement
FunctionDeclaration

That suggests to me that it is perfectly legal to nest functions to any
degree. I haven't checked to any great extent to see if the text notes
limitations or exceptions, but I doubt there are any.

One thing I had noticed in the grammar is that you may not place function
declarations directly within a statement. As far as I can see, function
statements may only occur in:

- The program source at the "root" level.
- Other functions (expressions or statements).
- An eval() argument.

That would make something like:

if(...) {
function myFunction() {
}
}

illegal. However, a quick test shows that (at least some) browsers support
it. Why you'd do something like this, though, is another question.

Mike
 
R

Richard Cornford

Nested function declarations and function expressions are supported by
Netscape 4 with JavaScript 1.3 and IE 4 (approx: JScript 2), about the
oldest browsers that remain viable as scriptable Internet user agents
(certainly the oldest considered for active support in a commercial
context, and often not then).

As is not unusual for such documents, the 3rd edition of ECMAScript was
formalising behaviour already common to implementations.

And has been a standard feature of browser scripting engine
implementations considerably longer.
Will I do?

Unless I'm missing something major (quite possible as I don't
have this thread in full), you seem to be suggesting that

function a() {
function b() {
}
}

is illegal. Is that correct? Well, in a code example, section
13.2 - Creating Function Objects, they have written almost
precisely the above.

If nested functions were not explicitly supported there would not be
much point in ECMA 262 (3rd edition) going into quite so much detail
about how the scope chain and the internal [[Scope]] properties are
handled, as there would be no ECMAScript circumstances where it would
make any difference (which is probably why the second edition can get
away with defining only one form of scope chain for any execution
context).
If you want the associated grammar:

FunctionDeclaration :
function Identifier ( FormalParameterListopt ) { FunctionBody }

FunctionBody :
SourceElements

SourceElements :
SourceElement
SourceElements SourceElement

SourceElement :
Statement
FunctionDeclaration

Yes, function bodies may explicitly contain function declarations, and
function expressions may appear anywhere that a MemberExpression can be
used:-

| 11.2 Left-Hand-Side Expressions
| Syntax
| MemberExpression :
| PrimaryExpression
| FunctionExpression
| MemberExpression [ Expression ]
| MemberExpression . Identifier
| new MemberExpression Arguments

That suggests to me that it is perfectly legal to nest functions
to any degree. I haven't checked to any great extent to see if
the text notes limitations or exceptions, but I doubt there are
any.

One thing I had noticed in the grammar is that you may not place
function declarations directly within a statement. As far as I
can see, function statements may only occur in:

- The program source at the "root" level.
- Other functions (expressions or statements).
- An eval() argument.

That would make something like:

if(...) {
function myFunction() {
}
}

illegal. However, a quick test shows that (at least some)
browsers support it.

More involved tests would show extremely inconsistent handling of that
code. The production rules forbid a function declaration form appearing
within a block statement so the only valid ECMAScript interpretation of
that is as a function expression with optional identifier, and just
asserted (never assigned to anything or called, so a pointless
expression).

In practice browsers may take it as a function declaration (unless
explicitly parenthesised, which makes it unambiguously an expression)
and act on it during variable instantiation (effectively removing it
form its block context), and Mozilla browsers treat it as an expression
but erroneously (by ECMA 262) leak the optional identifier into the
containing scope (producing an effect indistinguishable form a
conditional function declaration (if such existed in ECMAScript).
Why you'd do something like this, though, is another
question.

You wouldn't, but an inner function expression, conditionally evaluated
and assigned, is completely normal.

Richard.
 
T

Thomas 'PointedEars' Lahn

Richard said:
Yes, function bodies may explicitly contain function declarations,

ACK, but only at first level.
and function expressions may appear anywhere that a MemberExpression can
be used:-

| 11.2 Left-Hand-Side Expressions
| Syntax
| MemberExpression :
| PrimaryExpression
| FunctionExpression
| MemberExpression [ Expression ]
| MemberExpression . Identifier
| new MemberExpression Arguments

However, the flaw of the latter argument (if that is what it is supposed
to be) is that a FunctionExpression is not a FunctionDeclaration and
vice-versa.


PointedEars
 
D

Dr John Stockton

JRS: In article <[email protected]>, dated Sun, 17 Oct
2004 23:26:27, seen in Thomas 'PointedEars'
Lahn said:
Please stop posting attribution novels; the reasons have been explained
(to you) several times before.

They are invalid reasons. There is no support for them in accepted
Usenet standards and norms; and Usefor WIP allows a full attribution
such as I use.

You may recall that the German nation got rather a bad name in the early
1870s, the 1910s, and in 1933-45. It seems unwise of you to attempt to
repeat the situation single-handedly.

Given your rather silly habit of reviving ancient threads, threads that
the saner readers of c.l.j have long lost interest in, threads that are
no longer conveniently accessible to those using off-line newsreaders,
putting the date of the previous article in an attribution would be a
convenience to users of the group -- it is not always possible to
determine the date of a previous article from its message-ID in
References, and, when it is possible, many will not know how to do it,
and others find it inconvenient to understand.

In brief, pleas cease your Schickelgrubing.

I'd be happy to be wrong here and read about the required productions
from the ECMAScript 3 grammar in a posting of you.

They are supported in MSIE4, which Flanagan says is JS 1.2; that is over
six years old.
 
D

Dr John Stockton

JRS: In article <opsf1ccriyx13kvk@atlantis>, dated Sun, 17 Oct 2004
22:19:29, seen in Michael Winter <M.Winter@bl
ueyonder.co.invalid> posted :
That would make something like:

if(...) {
function myFunction() {
}
}

illegal. However, a quick test shows that (at least some) browsers support
it. Why you'd do something like this, though, is another question.

My IE4 allows it, but does not support it.

In other words, the condition is ignored, and the new function is always
defined.

It's easy to see that one might well want to replace a function that is
already defined, and that looks a reasonable way of doing it. There are
probably other ways, though, so that one is not necessary.
 
J

John G Harris

Thomas 'PointedEars' said:
Please stop posting attribution novels; the reasons have been explained
(to you) several times before.

It isn't, and you haven't.

I'd be happy to be wrong here and read about the required productions
from the ECMAScript 3 grammar in a posting of you.

I'm amazed that you can make such a dogmatic statement about ECMAScript
without being able to look it up.

You must read ECMA 262, v3, sections 13 and 14.

John
 
M

Michael Winter

JRS: In article <opsf1ccriyx13kvk@atlantis>, dated Sun, 17 Oct 2004
22:19:29, seen in Michael Winter
That would make something like:

if(...) {
function myFunction() {
}
}
[snip]

It's easy to see that one might well want to replace a function that is
already defined,

Of course. A self-configuring script could use it to replace a
decision-making function with a single code path. Initially, the function
tests the environment, and if it's sure that the browser will be
consistent, it could replace itself with code that uses a particular
feature set rather than selecting on each invocation, increasing the
performance of subsequent executions. I believe Richard used that in his
Russian Doll pattern demonstration, and I have, too (though to a simpler
extent).
and that looks a reasonable way of doing it. There are probably other
ways, though, so that one is not necessary.

The correct way would be:

var functionName = function( argumentList ) {
};

that is, a function expression. As function declarations are evaluated
when the relevant scope is entered, I'd imagine[1] that the last function
would always be the one referenced by the identifier, irrespective of
whatever conditional statements might surround it. That was why I asked
what the point would be.

Mike


[1] Read: untested. As it's not legal, so something I wouldn't do, I
haven't given it much attention. As Richard hinted, implementations will
probably vary anyway, so best avoid it. As you supposed: there are other
ways.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,830
Latest member
ZADIva7383

Latest Threads

Top