I have an object which contains a method that should execute every x ms. I
can use setInterval inside the object construct like this -

self.setInterval('ObjectName.methodName()', this.pinginterval);

- but is there no way to do this without using the literal ObjectName? If I
write 'this.methodName()' I get "Line 1 Char 1: Object doesn't support this
property or method." in IE, and nothing happens in Firebird.

--

I would write

 var myself = this;
 function callMethod() {
   myself.methodName();
 }
 setInterval(callMethod, this.pinginterval)

That way you don't rely on any literals being the same when the code
is executed, but rely on the normal scope rules to keep the *value* of
myself in the function's scope chain.

Daniel

But thank you for your post =)

function myObject() {
    var o = this;
    o.intervalcheck = function() { // blahblah }
    self.setInterval(o.intervalcheck, 2000);

And thank you =)

 function myObject() {
     var o = this;
     var f = function() { // blahblah };
     o.intervalcheck = f;               // seems unused otherwise
     self.setInterval(f, 2000);
 }

Functions have several roles in Javascript. They act both as first
class values (which is what we use when passing a function reference
to setInterval) and as methods of objects (which is what we do when we
invoke them as "object.method()"). However, these two roles are not
compatible.

When you write "o.intervalcheck", what you get is the reference to the
function. There is nothing in this reference that can tell that the
function has been a method of the "o" object. Calling the function later
will not make the "this" keyword point to the "o" object.

If the "//blahblah" uses "this", then it is probably a mistake. If it uses
"o", then it probably works. In either case, there doesn't seem to be any
reason for making the function a property of the object.

(Incidentally, because I just read a book about it, the concept of
passing an object method as a first class value has been incorporated
into the C# language. It is called a "delegate", and it works like a
function while retaining the binding of the "this" keyword. They do
have an easier time than javascript, since functions aren't first
class values otherwise.)

<snip>

It's been noted elsewhere that it seems to be a deficiency in
Javascript that "this" doesn't refer to the object upon entry to a
closure. Nonetheless, both private and public properties of the object
are accessible within the closure. As is the object itself, provided a
reference to the object has been preserved during object construction
(e.g., var o = this).

Thanks,
Daniel =)

I'll be reading up on objects in the Bible ;)

Thanks for your help, RH! =)

Daniel

Sorry for posting this after the other post, but it just struck me.

Closures are wonderful things and make JavaScript capable of doing
unusual and unexpected things but they are not totally without problems.

The first problem only effects IE and is more related to DOM interaction
and ActiveX than to pure JavaScript objects. It appears that if a DOM
Element or ActiveX object holds a reference to a JavaScript object (as
and expando property or event handling function reference) while that
object holds a reference to that DOM Element or ActiveX object then IE
will not garbage collect either even when navigating away from the page.
Scripts that form such circular reference effectively tie up ever
increasing amounts of memory until IE is closed.

The circular references can be more indirect, involving multiple
objects, but so long as they are circular and include a DOM element
(which includes the document object[1]) or an ActiveX object the problem
exists.

Closures, like all else in JavaScript are objects. At least they imply
the persistence of objects. Specifically, for the inner function of a
function to continue to have access to the local variables and
parameters of its outer function the 'variable' object from the
execution context of the outer function's invocation must continue to
exist. Closures risk forming circular references when, for example,
assigning an inner function to an event handling property of a DOM
element if the reference to the DOM element is held in a local variable
or an outer function parameter as these references will be preserved on
the variable object and the inner function object must have a reference
to that variable object (however indirect) in order to be able to refer
to the variables and parameters of its outer function.

Being aware of the problem, it is possible to limit the size and
contents of closures, null local variables that refer to DOM elements if
they are no longer needed and ultimately institute some sort of cleanup
to break any unavoidable circular references onunload.

The second problem with closures is that the inner functions are
function objects. Function objects need to be created (which has an
overhead) and consume memory. ECMA script allows implementations to
optimise the creation of function objects by "joining" function objects
that would be "indistinguishable". That optimisation is optional and
recent experiments have suggested that only Gecko browsers implement any
function joining and they do not currently do so for inner functions at
all. There is no evidence that IE or Opera do any joining at all.

The result is that a new function object will be created for each inner
function for each invocation of its outer function.

Consider:-

function MyObject(x){
    this.x = x;
    this.method = function(){
        return this.x;
    };

function MyObject(x){
    this.x = x;

The - method - method in the first example does fall into the category
of object methods that Douglas Crockford ( http://www.crockford.com )
has categorised as 'privileged', in that, if the closure formed by
this - MyObject - constructor had created private instance members then
the - method - method would be able to access those members. In the
example above there are no private members of the - MyObject - object
and the - method - method gains nothing by being "privileged".

My point being that the use of inner functions carries an overhead and
that makes me think that it would be best to restrict their use to
instances where the fact that they are inner functions, and thus in a
position to form and _exploit_ the resulting closures, has a manifest
advantage.

Lasse thinks that authoring convenience and ease of maintenance argue
against worrying about this aspect of inner functions to any significant
degree. I am a bit more obsessed with maximising performance. No one
else has expressed an opinion. Knowing the situation you can make up
your own mind about.

Richard.

The "this" keyword is a keyword, not an identifier. The "this" keyword
is set when you call a function as a method ("o.method()") but not when
you call a function reference directly ("var foo=o.method;foo()"). In the
latter case, the "this" keyword refers to the global object during the
execution of the body of "foo". The value of the "this" keyword depends
on how the function was called.

The scope of identifiers is textual, so when you write

 function foo () {
   var o = ...;
   function bar() {... o ...}
   ...
 }

then the "o" inside the "bar" function refers to the declaration
outside, because it is the closest textually enclosing declaration.
The "o" is declared for the entire function body of "foo". The "bar"
function is textually inside this body, so it is the scope of that
particualr declaration of "o". (Since "o" is a local variable, each
call to "foo" has its own, and each call to "foo" creates a new "bar")

If a "bar" function is passed around, the value leaving the scope
where it was declared, it will keep referring to the same local
variable of the particular call to the "foo" function where it was
created. That is the point of a closure.

As for the potential problem with circular references you describe, I'll
definitely have to take this into account. Your post was very informative,
and I probably wouldn't have realized this issue existed had it not been for
you, so thank you _very_ much for taking the time to write such an in-depth
reply! =)

Regards,
Daniel

"Lasse Reichstein Nielsen" <l...@hotpop.com> wrote in message
news:8yriv5w6.fsf@hotpop.com...

Thanks to you, RH, and Richard, I'm beginning to get a really good
understanding of this. You guys rock! The time and effort you're spending
here really means a lot to me (and others!) =)

Thanks,
Daniel

PS: Jeg har kigget lidt på din side - den der random art-dippedut er helt
vildt cool =)

The corresponding parent notation is "this.parentNode", which refers
to the parent in the DOM tree structure (which is not necessarily the
form element). You can crawl the tree using ".firstChild",
".nextSibling", etc.

I guess the people who first created the (pre-specification) DOM often
needed to refer to other elements of the same form, so the easiest was
to put a reference to the form where it was easily accessible: on each
element. I'll have to agree that it was a good choice.

"Lasse Reichstein Nielsen" <l...@hotpop.com> wrote in message
news:k7b2tp7b.fsf@hotpop.com...

Thanks! =)

Daniel

I like the idea of grouping all code related to an object into one
structure in a way similar to Java. It is still feasible to do that with
JavaScript without creating a unique function object for each method of
each object instance.

The following executes a function expression as the file loads, that
function call returns a function that will act as a class constructor.
The resulting closure acts as a repository for private static members
but it can also server to group the code for the entire class into one
function body. However, because this constructor returning function is
only called once any inner functions assigned to the prototype of the
constructor will be shared by all instances of the class and that gives
you the clear object code structure while not creating more function
objects than is needed.

var MyObject = function(){
    var counter = 0; //private static (class) member

    function incrementCounter(){  //private static (class) method.
        return counter++;
    };

    function constructor(id){ //class constructor.
        this.id = id;
        var self = this;

        //call private static (class) method and assign the returned
        //index to a private instance member.
        var index = incrementCounter();

        this.getIndex = function(){ //privileged instance method.
            return index;
        };
    };

    //privileged static (class) method (a property of the constructor)
    constructor.getNoOfInsts = function(){
        return counter;
    };

    //public instance method that is also privileged at the class
    //level. It has no access to the closure formed when
    //constructing new objects. The one function object is
    //shared by all instances of the class as it has been assigned
    //to the prototype of the constructor function.
    constructor.prototype.getId = function(){
        return this.id;
    }

    return constructor;  //return the constructor.

There is no need, but it also remains possible to extend the prototype
after the constructor has been returned from the one-off function
call.:-

MyObject.pubStatic = "anything"  //public static (class) member

MyObject.prototype.pubInstVar = 8;  //public instance member

Richard.

--

[*] This is my brain's way of expressing how expressions evaluate to
something else, like "now = theCurrentTime()" >>> theCurrentTime()'s "space"
in that expression is replaced with whatever's returned by the function. I
know it would be sufficient to just say "evaluate", but since I don't
understand this, I thought it would be a good idea to try to explain how my
failing brain understands this term ;)

What exactly the MyObject function then is, I don't quite understand. As it
is not itself instantiated, it can't see it anywhere existing as an object,
actually I can't see how the counter inside will keep its value from one
object construction to another, since it - in itself - is just a function?
And why is it only called once? As I see it it will be called every time you
do a "new MyObject()"... Ofcourse it must be because I don't fully
understand objects (or functions) in Javascript but the Bible's explanations
are REALLY tame. (OT, I think I need to buy a better book - any
suggestions?)

Or is the answer in the "new MyObject('anyId')" assignment?

As I understand your code, it's a function that, when executed, returns an
object constructer that is also executed, all the while keeping track of a
counter (in a way I don't understand).

Argh, I know it must be like dancing with an elephant to help me here, so
I'll definitely understand if you just tell me to go read a book ;)

In either case, thank you for your help, Richard!

Daniel

PS: In case of the "read a book" reply, which one should I get?

The primary purpose of the inline execution of the outer function is to
provide a closure to contain private static (class) members. Variables
and functions local to the closure but also available to any other
function defined within the same closure. Which includes the constructor
and the closure formed when new objects of the class are created, their
privileged and private methods and their non-privileged public members.
However, the function expression that is executed in-line also serves as
an enclosing structure for the entire class definition. Resulting in a
more Java-like class definition.

It is a MyObject instance because - if(test instanceof MyObject) - will
compare the reference to the function object that constructed - test -
with the with the function object referred to by the global MyObject
property. The identifier "constructor" is out of scope outside the
closure formed by executing its outer function in-line.

When I was first learning JavaScript "Javascript the Definitive Guide"
(then it its second edition) was the most useful book I had, but for its
DOM reference rather than its language coverage (which is still much
better than the other JavaScript books I have seen).

You will be lucky to find any reference to Douglas Crockford's
application of closures to provide JavaScript objects with private
instance members, or my application of his technique at the constructor
level to provide JavaScript classes with private static members. I even
have JavaScript books that assert that JavaScript objects cannot have
private members (of any type).

Incidentally, avoid books about JavaScritp 2. The next revision of the
ECMA Script language has not been finalised yet so anything about
JavaScript 2 is speculation based on proposals and one or two reference
implementations. It won't be practical for client-side use for at least
4 years anyway.

Richard.

King of the Finger Lakes wrote:

Then, we have the first (and last) execution of *that particular* function
when we (if we read it literally (and I still do that a lot ;)) try to
instantiate it *as if it were* an object constructor. Javascript says, "you
want an instance of that object?" and checks to see what "that object" is,
i.e. the function is evaluated. The function starts its work and ends up
returning its inner constructor function, but not just that, because if it
did, you'd end up using the "new" keyword on an object constructor
*function* object, and not an object *constructor*. No, it uses that one-off
thingie to evaluate the function object to become the object constructor, so
that the assignment argument becomes valid, and the "test" var becomes an
instance of what the MyObject is *now*, which is the object constructor
inside the function is was before. I actually understand it as if the
constructor inside "MyObject" effectively hijacks the variable name and
reference to "MyObject", cutting its connection to the public while
retaining access to its properties and methods for its own members (the
closure).

Now, at every new MyObject instantiation, using "new" on "MyObject" doesn't
execute the orginial function (that reference is lost), but reaches straight
inside it to the object constructor class that provides all its instances
with access to its outer function's resources. (And it can keep track of the
counter since incrementCounter is now an outer function to itself :)

Did I get it? =)

On a side note, since English isn't exactly my mother tongue, and although I
believe I'm better at it than many of my fellow Danes (well, maybe not Lasse
, but others ;), I do have a tendency to mix up words and phrases, and
sometimes simply talk nonsense (also in the text above, I'm sure). Of course
it doesn't help either that I'm learning a programming language through a
foreign language (I mean, phrases like "The primary purpose of the inline
execution of the outer function is to provide a closure to contain private
static (class) members" I have to read a few times before they sink in,
hehe). I apologize for when this results in having to repeat and rephrase
things to me that should be clear the first time, and when it makes me seem
even more daft than I am ;)

That said, I have never understood objects better than I do right now! =)

Thank you, Richard! For your time, your patience, your links, and book tips
=)

Daniel

PS: