Error Object Expected

[westplastic]

This one is driving me insane. The script works perfect on Firefox,
but Internet Explorer keeps complaining about "Error Object Expected"
and stuff like that. I've run it through Firefox's Java Console, and
it comes back with no errors. Any pointers on this, would be much
appreciated.

<script type="text/javascript">
<!--
var p = new Array(0,0,0,0,0)
var c = new Array(0,0,0,0,0,0,0,0,0)

var classes = new Array(5)
classes[0] = "<a href='javascript:class(0)'>ASM2O<\/a><div
id='c0'><\/div><a href='javascript:class(1)'>PPL2O<\/a><div
id='c1'><\/div>"
classes[1] = "<a href='javascript:class(2)'>SNC2D<\/a><div
id='c2'><\/div><a href='javascript:class(3)'>CHC2D<\/a><div
id='c3'><\/div>"
classes[2] = "<a href='javascript:class(4)'>ENG2D<\/a><div
id='c4'><\/div><a href='javascript:class(5)'>MPM2D<\/a><div
id='c5'><\/div>"
classes[3] = "<a href='javascript:class(6)'>break<\/a><div
id='c6'><\/div>"
classes[4] = "<a href='javascript:class(7)'>GLC2O<\/a><div
id='c7'><\/div><a href='javascript:class(8)'>BBI2O<\/a><div
id='c8'><\/div>"

var hom = new Array(8)
hom[0] = "<ul><li>Motion tweening<\/li><li>Shape
tweening<\/li><li>Splice<\/li><li>Motion guides<\/li><\/ul>"
hom[1] = "<ul><li>Stuff<\/li><\/ul>"
hom[2] = "<ul><li>Megatransect II<\/li><li>Worksheet<\/li><li>10.3
#1-14<\/li><\/ul>"
hom[3] = "<ul><li>Stuff<\/li><\/ul>"
hom[4] = "<ul><li>Read 2.1<\/li><li>Redo journal<\/li><\/ul>"
hom[5] = "<ul><li>Stuff<\/li><\/ul>"
hom[6] = "<ul><li>You think you can get homework from a lunch
period?<\/li><\/ul>"
hom[7] = "<ul><li>Technology careers presentation<\/li><\/ul>"
hom[8] = "<ul><li>Stuff<\/li><\/ul>"

function display(period){
if(p[period]==0){
document.getElementById("p"+period).innerHTML=clas ses[period]
p[period]=1
}
else{
document.getElementById("p"+period).innerHTML=""
p[period]=0
}
}

function class(num){
if(c[num]==0){
document.getElementById("c"+num).innerHTML=hom[num]
c[num]=1
}
else{
document.getElementById("c"+num).innerHTML=""
c[num]=0
}
}
//-->
</script>
----------------------------------------------------------------------------
You can see the script in context here:
http://www.freewebs.com/cisbase/Mich.../homework.html

The gist of it, is that a link is clicked which calls display(period).
This will then display the appropriate element from classes[] which in
turn provides a link that calls class(num) and displays the
corresponding element from hom[]

Again, works nice on Firefox.

Internet Explorer:
Upon loading, it gives this error:
Line: 42
Char: 10
Error: Expected '('
Code: 0

And when clicking one of the links it gives this error
Line: 1
Char: 1
Error: Object Expected
Code: 0

[VK]

we*********@gmail.com wrote:

This one is driving me insane. The script works perfect on Firefox,
but Internet Explorer keeps complaining about "Error Object Expected"
and stuff like that. I've run it through Firefox's Java Console, and
it comes back with no errors. Any pointers on this, would be much
appreciated.

"class" is a reserved word in JScript, you cannot use it as identifier.

Keep this table near of your comp:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsconreserved.asp>

[westplastic]

> "class" is a reserved word in JScript, you cannot use it as identifier.

Gah, I should have known that, thanks for the quick response.

[Tony]

>The script works perfect on Firefox,

but Internet Explorer keeps complaining about "Error Object Expected"
and stuff like that. I've run it through Firefox's Java Console, and
it comes back with no errors.

Another case where I've experienced EXACTLY the same behavior is when
I've left off "var" on a variable creation/assignment, and the variable
is being assigned an object. IE doesn't like that, but Firefox seems to
accept it. In these cases, putting in "var" inevitably fixes the
problem.

Not exactly your specific case, it seems, but it is another case where
the same error pops up.

[RobG]

VK wrote:

we*********@gmail.com wrote:

This one is driving me insane. The script works perfect on Firefox,
but Internet Explorer keeps complaining about "Error Object Expected"
and stuff like that. I've run it through Firefox's Java Console, and
it comes back with no errors. Any pointers on this, would be much
appreciated.

"class" is a reserved word in JScript, you cannot use it as identifier.

Keep this table near of your comp:
<http://msdn.microsoft.com/library/default.asp?url=/library/en-us/script56/html/js56jsconreserved.asp>

Probably worth pointing out that the Netscape proposal for JavaScript
2.0 includes classes, so the keyword 'class' will, if the proposal is
adopted, actually have some meaning.

<URL:http://www.mozilla.org/js/language/js20/core/classes.html>

--
Rob

[VK]

RobG wrote:

Probably worth pointing out that the Netscape proposal for JavaScript
2.0 includes classes, so the keyword 'class' will, if the proposal is
adopted, actually have some meaning.

<URL:http://www.mozilla.org/js/language/js20/core/classes.html>

Hi, RobG
I hope I'm not yet in your kill-file
:-(

"class" already has perfect meanning in JScript.Net - I'm just enjoying
it and waiting the "Empire strikes back" from Mozilla.

Actually it always puzzled me:

/* This is Java */
/* This is the class: */
class myObject {
int foo;
String bar;

/* This is the class constructor: */
public void myObject(String str) {
this.foo = 1;
this.bar = str;
}

/* This is the private member: */
private String methodOne() {
return this.bar
}

/* This is the public member: */
public String methodTwo() {
return methodOne();
}
}

..
..
..

/* This is JavaScript */

/* This is uhm... just constructor
but is has prototype which is *not* a class */
function myObject(str) {
this.foo = 1;
this.bar = str;

/* This is the public member: */
this.methodTwo = function() {return methodOne();}

/* This is the private member: */
function methodOne() {
return this.bar
}
}

Whoever doesn't see a global difference between JavaScript prototype
and Java class (lesser strict typed vs. loose typed issues) is a
complete idiot.

OK, I am one. (what a news anyway!)

[RobG]

VK wrote:

RobG wrote:

Probably worth pointing out that the Netscape proposal for JavaScript
2.0 includes classes, so the keyword 'class' will, if the proposal is
adopted, actually have some meaning.

<URL:http://www.mozilla.org/js/language/js20/core/classes.html>

Hi, RobG
I hope I'm not yet in your kill-file
:-(

Then my response will expose you to those that haven't done so to me
(yet) ;-p


"class" already has perfect meanning in JScript.Net - I'm just enjoying
it and waiting the "Empire strikes back" from Mozilla.
Mozilla.org is committed to open standards, the owners of JScript.NET
are not, hence the 'zilla guys have gone about it differently.

Having said that, if the Mozilla developers want to do their own thing
there is nothing to stop them - they have plenty of 'proprietary'
extensions in the Geko DOM - but extending JavaScript itself with
classes is a pretty fundamental shift and quite a different thing.

If classes are introduced in JavaScript 2.0/ECMAScrpipt Edition 4, it
will be interesting to see what happens with JScript.NET classes - how
compatible are they with Waldemar Horwat's proposal?
[...] /* This is JavaScript */

/* This is uhm... just constructor
but is has prototype which is *not* a class */
function myObject(str) {
this.foo = 1;
this.bar = str;

/* This is the public member: */
this.methodTwo = function() {return methodOne();}
It could also be called a privileged member since it has access to the
private member methodOne() - if my understanding of the terminology is
correct.


/* This is the private member: */
function methodOne() {
return this.bar
}
}

Whoever doesn't see a global difference between JavaScript prototype
and Java class (lesser strict typed vs. loose typed issues) is a
complete idiot.

I'm not qualified to comment.

Mistakes were made with JavaScript, Brendan Eich acknowledges that - he
wrote the original prototype in about one week. Fixing those mistakes
will be painful (if attempted) - are the benefits worth it?

Once a language is as widely adopted as JavaScript, it is very hard to
change it - backward compatibility rears its ugly head. It is very
important to get it right first time (though that will not always happen).

Let's not loose sight of the original intention of JavaScript (Mocha) to
be a simple language that is easy for anyone to implement. Brendan Eich
has a presentation that includes 'JavaScript in two slides'[1], complex
stuff was supposed to be done with Java. Perhaps the lethargy with
which JavaScript is moving toward it's next version is an indicator that
most are happy with it just as it is.

If ECMAScript Edition 4 is not adopted as a standard soon, will Mozilla
go it alone and hope the other open source folk follow/help out?
1. <URL:http://www.mozilla.org/js/language/ICFP-Keynote.ppt>
--
Rob

[Thomas 'PointedEars' Lahn]

RobG wrote:

VK wrote:

RobG wrote:

Probably worth pointing out that the Netscape proposal for JavaScript
2.0 includes classes, so the keyword 'class' will, if the proposal is
adopted, actually have some meaning.
"class" already has perfect meanning in JScript.Net - I'm just enjoying
it and waiting the "Empire strikes back" from Mozilla.

Mozilla.org is committed to open standards, the owners of JScript.NET
are not, hence the 'zilla guys have gone about it differently.

However, JScript 7.0 (.NET) claims to be compliant to ECMAScript 4 in parts.

<http://msdn.microsoft.com/library/en-us/jscript7/html/jsgrpecmafeatures.asp>
Having said that, if the Mozilla developers want to do their own thing
there is nothing to stop them - they have plenty of 'proprietary'
extensions in the Geko DOM
It is the other way around. The Gecko DOM (as any DOM) is proprietary
by design (and history), however it implements interfaces of the W3C DOM.
- but extending JavaScript itself with
classes is a pretty fundamental shift and quite a different thing.

If classes are introduced in JavaScript 2.0/ECMAScrpipt Edition 4,
What do you mean -- if? They are already introduced, there is even a test
implementation for ECMAScript 4 called Epimetheus. What is needed now is
a decent specification out of the proposal and a real implementation in a
browser. Hopefully in Mozilla/5.0 rv:1.8 or rv:2.0.
it will be interesting to see what happens with JScript.NET classes
- how compatible are they with Waldemar Horwat's proposal?
Quite, regarding the new language features.
[...]

/* This is JavaScript */

/* This is uhm... just constructor
but is has prototype which is *not* a class */
function myObject(str) {
this.foo = 1;
this.bar = str;

/* This is the public member: */
this.methodTwo = function() {return methodOne();}
It could also be called a privileged member since it has access to the
private member methodOne() - if my understanding of the terminology is
correct.

You're right. However, the syntax used by VK is (surprise!) not
ECMAScript compliant. FunctionStatements must not occur within
FunctionStatements; instead, FunctionExpressions must be used.
Perhaps this is going to change in ECMAScript 4 as the proposal
says so:

| FunctionDefinition => function FunctionName FunctionCommon
| ...
| FunctionCommon => ( Parameters ) Result Block
| ...
| Block => { Directives }
| Directives =>
| «empty»
| | DirectivesPrefix Directive^abbrev
| DirectivesPrefix =>
| «empty»
| | DirectivesPrefix Directive^full
| Directive^? =>
| ...
| | AnnotatableDirective^?
| ...
| AnnotatableDirective^? =>
| ...
| | FunctionDefinition
| ...
If ECMAScript Edition 4 is not adopted as a standard soon,
Wait a minute. It is currently still a Netscape proposal, it rather
looks to me like a working draft. It was maintained by waldemar who
also contributed to ECMAScript 3, however the I don't know if he is
still working for Netscape. Since the AOHell/TW takeover of Netscape,
all Netscape-related stuff somehow fall asleep, including ECMAScript 4.
will Mozilla go it alone and hope the other open source folk follow/help
out?
I doubt that. I liked to think someone from the inner core would check
ECMAScript 4 and propose it to ECMA as the Mozilla Foundation is a member.
Apparently, according to Brendan, that has happened now (September 26-28,
2005), which I was relieved to read. Standardization takes time, so we
should give them the time. Rushing it now will only result in the same
old errors again.
1. <URL:http://www.mozilla.org/js/language/ICFP-Keynote.ppt>

IMHO a shame to be found in this format at mozilla.org. Have they become so
Microsoftish there over the last months? First document.all and now this.
I have OpenOffice that supports PPT, but still ... :-(
PointedEars

[RobG]

Thomas 'PointedEars' Lahn wrote:

RobG wrote:
[...]

- but extending JavaScript itself with
classes is a pretty fundamental shift and quite a different thing.

If classes are introduced in JavaScript 2.0/ECMAScrpipt Edition 4,

What do you mean -- if?

I meant *with* JavaScript 2.0/ECMAScript Edition 4.

That is, when they start to become widely in web page scripts and
classes start being used. From what you have said regarding the Mozilla
browser, JavaScript 2.0 is very nearly here.

I presume that means other Geko-based browsers will adopt it too, other
open source browsers will surely not be far behind.
[...]
You're right. However, the syntax used by VK is (surprise!) not
ECMAScript compliant. FunctionStatements must not occur within
FunctionStatements; instead, FunctionExpressions must be used.
The subtleties of the lingo sometimes completely evade me ... I had to
use the Mozilla documentation to sort that out. A function statement is:

function [name] ([parm1, parm2, ...]) {statements};
and a function expression is:

var x = function [name] ([parm1, parm2, ...]) {statements};
<URL:http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions#The_functi on_declaration_.28function_statement.29>
Incidentally, the new-look documentation in Wiki format is great! (hint
to FAQ administrators/maintainers!!).
[...]

If ECMAScript Edition 4 is not adopted as a standard soon,

Wait a minute. It is currently still a Netscape proposal, it rather
looks to me like a working draft. It was maintained by waldemar who
also contributed to ECMAScript 3, however the I don't know if he is
still working for Netscape. Since the AOHell/TW takeover of Netscape,
all Netscape-related stuff somehow fall asleep, including ECMAScript 4.

'Soon' is relative. It's been what, 4 years in the making already? The
"Netscape" proposal started 5 years ago, hasn't changed in over 2 years
(if the change history is correct[1])... given JavaScript went from
nothing to 1.5 in a little over 3 years, gimme back the browser wars!! ;-p

That really is just a joke, but episodes (sagas?) such at that are
amazing drivers of innovation and invention.

will Mozilla go it alone and hope the other open source folk follow/help
out?

I doubt that. I liked to think someone from the inner core would check
ECMAScript 4 and propose it to ECMA as the Mozilla Foundation is a member.
Apparently, according to Brendan, that has happened now (September 26-28,
2005), which I was relieved to read. Standardization takes time, so we
should give them the time. Rushing it now will only result in the same
old errors again.

You at least seem hopeful that JS 2.0 will see the light of day, maybe
sometime in 2006?
[...]
1. <URL:http://www.mozilla.org/js/language/es4/index.html>
--
Rob

[Richard Cornford]

RobG wrote:

Thomas 'PointedEars' Lahn wrote:

<snip>

... . FunctionStatements must not occur within
FunctionStatements; instead, FunctionExpressions
must be used.

The subtleties of the lingo sometimes completely evade
me ... I had to use the Mozilla documentation to sort
that out. A function statement is:

function [name] ([parm1, parm2, ...]) {statements};

and a function expression is:

var x = function [name] ([parm1, parm2, ...]) {statements};

<snip>

The strange part of this is that there is no FunctionStatement in ECMA
262 3rd edition.

<quote cite="ECMA 262 3rd edition: Section 13">
13 Function Definition

Syntax

FunctionDeclaration :
function Identifier ( FormalParameterListopt ) { FunctionBody }

FunctionExpression :
function Identifieropt ( FormalParameterListopt ) { FunctionBody }

FormalParameterList :
Identifier
FormalParameterList , Identifier

FunctionBody :
SourceElements
</quote>

In which the contents of a function (expression or declaration) are
SourceElements, defined as:-
<quote cite="ECMA 262 3rd edition: section 14">
14 Program

Syntax

Program :
SourceElements

SourceElements :
SourceElement
SourceElements SourceElement

SourceElement :
Statement
FunctionDeclaration
</quote>

Where SourceElements are defined as any number of Statements and
FunctionDeclarations, so all functions (expressions or declarations),
may contain FunctionDeclarations.

Richard.

[Thomas 'PointedEars' Lahn]

RobG wrote:

Thomas 'PointedEars' Lahn wrote:

RobG wrote: [...]

- but extending JavaScript itself with
classes is a pretty fundamental shift and quite a different thing.
If classes are introduced in JavaScript 2.0/ECMAScrpipt Edition 4,

What do you mean -- if?

I meant *with* JavaScript 2.0/ECMAScript Edition 4.

That is, when they start to become widely in web page scripts and
classes start being used.

ACK
From what you have said regarding the Mozilla browser, JavaScript 2.0 is
very nearly here.
Well, no. We are at JavaScript 1.6 in betas/RCs and there is no release of
Mozilla/5.0 rv:1.8 yet. I do hope that rv:2.0 will bring JavaScript 2.0;
if I were responsible, it could be earlier if the result is reasonable :)
I presume that means other Geko-based browsers will adopt it too, other
open source browsers will surely not be far behind.
Me too. BTW: it is spelled G-E-C-K-O.

You're right. However, the syntax used by VK is (surprise!) not
ECMAScript compliant. FunctionStatements must not occur within
FunctionStatements; instead, FunctionExpressions must be used.

The subtleties of the lingo sometimes completely evade me ... I had to
use the Mozilla documentation to sort that out. A function statement is:

function [name] ([parm1, parm2, ...]) {statements};
and a function expression is:

var x = function [name] ([parm1, parm2, ...]) {statements};

<URL:http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Functions#The_functi on_declaration_.28function_statement.29>

Yes, but as Richard said, it is FunctionDeclaration instead of
FunctionStatement, and the difference with FunctionExpression
is that for the latter no identifier (not: name) is required.
Incidentally, the new-look documentation in Wiki format is great! (hint
to FAQ administrators/maintainers!!).
:)
[...]

If ECMAScript Edition 4 is not adopted as a standard soon,
Wait a minute. It is currently still a Netscape proposal, it rather
looks to me like a working draft. It was maintained by waldemar who
also contributed to ECMAScript 3, however the I don't know if he is
still working for Netscape. Since the AOHell/TW takeover of Netscape,
all Netscape-related stuff somehow fall asleep, including ECMAScript 4.

'Soon' is relative. It's been what, 4 years in the making already?
The "Netscape" proposal started 5 years ago, hasn't changed in over 2
years (if the change history is correct[1])...

Yes, indeed.
given JavaScript went from nothing to 1.5 in a little over 3 years,
gimme back the browser wars!! ;-p
*g*
That really is just a joke, but episodes (sagas?) such at that are
amazing drivers of innovation and invention.

I agree. I can only assume that and Microsoft's JScript.NET approach based
on what is not even a specification (but cited by them as such) is why it
is pushed now, perhaps by Brendan Eich himself.

will Mozilla go it alone and hope the other open source folk follow/help
out?

I doubt that. I liked to think someone from the inner core would check
ECMAScript 4 and propose it to ECMA as the Mozilla Foundation is a
member. Apparently, according to Brendan, that has happened now
(September 26-28, 2005), which I was relieved to read. Standardization
takes time, so we should give them the time. Rushing it now will only
result in the same old errors again.

You at least seem hopeful that JS 2.0 will see the light of day, maybe
sometime in 2006?

Yes, would have been about time :)
Regards,
PointedEars

[Thomas 'PointedEars' Lahn]

Richard Cornford wrote:

RobG wrote:

Thomas 'PointedEars' Lahn wrote: <snip>

... . FunctionStatements must not occur within
FunctionStatements; instead, FunctionExpressions
must be used.

The subtleties of the lingo sometimes completely evade
me ... I had to use the Mozilla documentation to sort
that out. A function statement is:

function [name] ([parm1, parm2, ...]) {statements};

and a function expression is:

var x = function [name] ([parm1, parm2, ...]) {statements};

<snip>

The strange part of this is that there is no FunctionStatement in
ECMA 262 3rd edition.

Correct.
[...]
Where SourceElements are defined as any number of Statements and
FunctionDeclarations, so all functions (expressions or declarations),
may contain FunctionDeclarations.

True, sorry, my bad. I mixed that up completely, probably because of
_conditional_ FunctionDeclaration via IfStatement that is not allowed.
Looking through my source code, I even found inner functions defined
through FunctionDeclarations at times.

However, I do think ECMAScript 4 would make a difference here since the
Block production can produce a FunctionDeclaration (or FunctionDefinition")
there where it could not in ECMAScript 3. But then, it is still only a
working draft.
PointedEars