Classes

[Guest]

I am getting an "Object Expected" error on line 0. Do you see anything
wrong with the following code:



var iTest = 60

function test(msg)
{
var NewMessage = msg;
StartIt(NewMessage);


function DisplayMessage(theMessage)
{
alert(iTest + theMessage);
}

function StartIt(theMessage)
{
var timer;
timer = setInterval("DisplayMessage('" + theMessage + "')",2000);
}

}


Thank you in advance

The email address is valid.

 

[RobG]

I am getting an "Object Expected" error on line 0. Do you see anything
wrong with the following code:

Because DisplayMessage() is defined as a local variable of test().
setInterval() attempts to run it from a global context so it can't find it.

var iTest = 60

function test(msg)
{
var NewMessage = msg;

Varialbes starting with a capital letter usually signifies that they
will be used as a constructor - just a convention.

StartIt(NewMessage);


function DisplayMessage(theMessage)
{
alert(iTest + theMessage);
}

function StartIt(theMessage)
{
var timer;
timer = setInterval("DisplayMessage('" + theMessage + "')",2000);

var timer = setInterval(function(){
DisplayMessage(theMessage);
},2000);


However that creates a closure and may cause memory leak problems in
some (buggy) browsers.

 

[Thomas 'PointedEars' Lahn]

I am getting an "Object Expected" error on line 0. Do you see anything
wrong with the following code:

Plenty. However, let us begin with the fact that there are no classes in
the language version you use.

var iTest = 60

Avoid global variables.

function test(msg)
{
var NewMessage = msg;

This variable declaration is redundant, `msg' is already a local variable.

StartIt(NewMessage);


function DisplayMessage(theMessage)
{
alert(iTest + theMessage);
}

function StartIt(theMessage)
{
var timer;
timer = setInterval("DisplayMessage('" + theMessage + "')",2000);
}

}

DisplayMessage() and StartIt() are inner functions of test(). They are
not a method of `test' objects, nor is there a `test' class (see above).
setInterval() is in fact the same method as window.setInterval() which
evaluates its argument in global context always. However, because
DisplayMessage() is not defined in global context, only in the local
one if test(), you get the useless error message from Internet Explorer.
(Try the JavaScript/Error Console a Gecko-based or Opera-based browser
instead. See also <URL:http://jibbering.com/faq/#FAQ4_43>.)

A reasonable solution would include proper application of prototype-based
inheritance, something like

function Test(msg)
{
this.test = 60;
this.startIt(msg);
}

Test.prototype = {
displayMessage: function test_displayMessage(theMessage)
{
alert(this.test + theMessage);
},

startIt: function test_startIt(theMessage)
{
this.timer = window.setInterval(
function()
{
this.displayMessage(theMessage);
},
2000);
}
};
Test.prototype.constructor = Test;

var t = new Test("foo");

Caveat: This will not work in IE before version 5.0, and NN before
version 1.3. <URL:http://pointedears.de/scripts/js-version-info>

You will find that yours is quite a FAQ here. Please do research
before you post.

The email address is valid.

True, however a name would be nice. I, for one, do not like talking
to e-mail addresses (or companies); I like talking to people


PointedEars

 

[Guest]

Plenty. However, let us begin with the fact that there are no classes in
the language version you use.


Avoid global variables.


This variable declaration is redundant, `msg' is already a local variable.


DisplayMessage() and StartIt() are inner functions of test(). They are
not a method of `test' objects, nor is there a `test' class (see above).
setInterval() is in fact the same method as window.setInterval() which
evaluates its argument in global context always. However, because
DisplayMessage() is not defined in global context, only in the local
one if test(), you get the useless error message from Internet Explorer.
(Try the JavaScript/Error Console a Gecko-based or Opera-based browser
instead. See also <URL:http://jibbering.com/faq/#FAQ4_43>.)

A reasonable solution would include proper application of prototype-based
inheritance, something like

function Test(msg)
{
this.test = 60;
this.startIt(msg);
}

Test.prototype = {
displayMessage: function test_displayMessage(theMessage)
{
alert(this.test + theMessage);
},

startIt: function test_startIt(theMessage)
{
this.timer = window.setInterval(
function()
{
this.displayMessage(theMessage);
},
2000);
}
};
Test.prototype.constructor = Test;

var t = new Test("foo");

Caveat: This will not work in IE before version 5.0, and NN before
version 1.3. <URL:http://pointedears.de/scripts/js-version-info>

You will find that yours is quite a FAQ here. Please do research
before you post.


True, however a name would be nice. I, for one, do not like talking
to e-mail addresses (or companies); I like talking to people


PointedEars

Thank you both for your replies. I have learned a lot. I greatly
appreciate it.

Thanks again,
Kent

 

[Guest]

After implementing the code you provided I got the following error:
Line 19 Object doesn't support this property or method.
Line 19 is:
this.displayMessage(theMessage);
If I change this to:
test_displayMessage(theMessage);
it almost works. The error goes away but I get undefinedfoo. I would
assume this means the code doesn't "see" test = 60. Why would this be?
Also, is the change I made, the correct change to the code?

Thanks again for you help,
Kent

 

[Lasse Reichstein Nielsen]

A reasonable solution would include proper application of prototype-based
inheritance, something like

function Test(msg)
{
this.test = 60;
this.startIt(msg);
}

Test.prototype = {
displayMessage: function test_displayMessage(theMessage)
{
alert(this.test + theMessage);
},

startIt: function test_startIt(theMessage)
{
this.timer = window.setInterval(
function()
{
this.displayMessage(theMessage);

The "this" operator in this context will refer to the global object as
well, when the function is called by the setInterval timer.

A way to capture the correct value in the closure would be:
...
var self = this;
this.timer = window.setInterval(
function() {
self.displayMessage(theMessage);
...

},
2000);
}
};
Test.prototype.constructor = Test;

This could be moved into the object literal too, or instead of
assigning to the prototype property, one could assing properties to
the existing prototype object, which already has this value.

/L

 

[VK]

A way to capture the correct value in the closure would be: ...
var self = this;

"self" is a property of window object (self-reference to the current
window):
self.alert('OK'); // equals window.alert('OK') in the global scope

Usually it is not recommended to override host object properies unless
required by the augmentation logic.

To fix the "incontinence of this" issue I would suggest to use some
unifirmed identifier instead - like $ (just a suggestion).

 

[Michael Winter]

"self" is a property of window object (self-reference to the current
window):

What exactly does that have to do with anything? The variable defined
above will be a local variable; a property of the Variable object for
the test_startIt function. Resolution of this identifier through the
scope chain will find it in that location before the global object is
reached and searched.

self.alert('OK'); // equals window.alert('OK') in the global scope

No-one denies that in most object models, both the self and window
global variables refer to the global object. It's just that most will
realise that it's irrelevant in this scenario.

Usually it is not recommended to override host object properies
unless required by the augmentation logic.

The global variable will not be overwritten.

To fix the "incontinence of this" issue I would suggest [...]

I would suggest that you learn to understand how ECMAScript-based
languages work before trying to correct others.

Mike

 

[VK]

I would suggest that you learn to understand how ECMAScript-based
languages work before trying to correct others.

I'm sorry, but you may drop this paternizing tone with me. Richard
alone is more then enough - "the horse cannot hold both"

Please: I did *not* say that the posted code will not work - it will. I
just questionned the real need to shadow the global "self" reference in
the function.

 

[Michael Winter]

On 01/03/2006 12:40, VK wrote:

[snip]

Please: I did *not* say that the posted code will not work - it will.

But you did imply that it will "override host object properies [sic]",
when such a statement is quite simply false.

I just questionned the real need to shadow the global "self"
reference in the function.

You haven't made a case for why it should be avoided. There is no direct
reference to the global object at all, let alone through a global
'self'. The word 'self' as an identifier is quite appropriate in this
case, and it isn't so frequently used nor important enough that its
redefinition would be confusing (as might be the case with 'document' or
'window', for example).

Mike

 

[Lasse Reichstein Nielsen]

"self" is a property of window object (self-reference to the current
window):
self.alert('OK'); // equals window.alert('OK') in the global scope

True, in browsers.

Usually it is not recommended to override host object properies unless
required by the augmentation logic.

You are not overriding it, but creating a new, local, variable of the
same name. Since you write everything in that scope, you have full
control over the variables used, so there should be no problem.
Also, the "self" property of the global object is irrelevant, since
it just points to the global object anyway, and the window property
does the same.

That said, a more meaningful name wouldn't be bad, but what it is
would depend on what type of object the variable holds.

Some would use "_this". I dislike that notation, and find it confuzing,
since it is exactly *not* the value of "this" when it is used.

To fix the "incontinence of this" issue I would suggest to use some
unifirmed identifier instead - like $ (just a suggestion).

That's what I use "self" for. I use it consistently when I just need
an identifier to hold the value of "this" for a closure.

/L

 

[Richard Cornford]

"self" is a property of window object (self-reference to
the current window):
self.alert('OK'); // equals window.alert('OK') in the
global scope
Irrelevant.

Usually it is not recommended to override host object properies
unless required by the augmentation logic.

Exactly how many times do you need to be told that no overriding of host
object properties happens when assigning a value to a local variable? I
have told you at least twice and others have said the same. But then you
have demonstrated that you don't really understand what a local variable
is so maybe it is not surprising that you cannot understand why no
overriding of host object properties happens. You really need to learn
the basics of this language to avoid making yourself look a fool by
repeating erroneous nonsense.

To fix the "incontinence of this" issue

You have never demonstrated that any "incontinence of this" issue
exists, even though you have been asked to explain what it is you are
wittering on about on many occasions.

The - this - keyword stands for a particular and well-defined and
understood value in all ECMAScript implementations. It is utterly
predictable and reliable. If you cannot comprehend its role that is most
likely because you prefer to comprehend javascript as voodoo instead of
deterministic mechanical logic.

I would suggest to use some unifirmed

"unifirmed"? If I look am I going to find that in any dictionary?

identifier instead - like $ (just a suggestion).

And unsurprisingly that is precisely the worst Identifier that could be
proposed for the task. It is inherently obscure and it would be being
used in direct contradiction of the convention laid down in ECMA 262,
3rd ed. section 7.6, (last sentence of) paragraph 2. Which means that
any knowledgeable javascript author would look at the identifier and
wonder what this Identifier asserting its machine-generated-ness was
doing there, wasting there time as a result of being needlessly
misdirected. Another maintenance burden added to that mush that you
write under the label 'javascript'.

Richard.