Question about Javascript classes and execution

[Tom Cole]

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.
If I place either an alert between the two requests or run the second
through a setTimeout of only 1 millisecond, they both work. You can
see a working example here: http://www.lamatek.com/Ajax/test.html.

I'm hoping some of you Javascript experts can help me with why this is
happening.

Thanks in advance.

[Richard Cornford]

On Mar 1, 1:33 pm, "Tom Cole" <tco...@gmail.c omwrote:

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.
If I place either an alert between the two requests or run the second
through a setTimeout of only 1 millisecond, they both work. You can
see a working example here:http://www.lamatek.com/Ajax/test.html.

I'm hoping some of you Javascript experts can help me with why this is
happening.

Your code is written to achieve chaotic behaviour, and chaotic
behaviour is what you get. In the example page both of - r1 - and - r2
- share the same function object as their - doTextRequest - method,
and that method only has the ability to reference a single copy of the
closure formed when - r2 - is instantiated.

Superficially your problem is assigning function objects to properties
of the prototype of AjaxRequest. These function objects cause a
closure to be created, but the closure in use changes whenever a new
AjaxRequest is created, and all pre-existing AjaxRequest instances
find their methods attached to the last closure formed.

Sharing that 1st closure produces the symptoms you describe, as the
second request effectively replaces the object assigned to - xmlhttp -
with the last request made. The chaos comes in because if you made a
first request, instantiated a new AjaxRequest object and then made a
second request (even through any pre-existing AjaxRequest object) you
would not get the collision (as it would be operating in a now
abandoned closure), but a third request made before the completion of
the second and your are back to where you started. Thus you have
behaviour varying with how your code is used (and so if triggered by
user interaction, behaviour depending on the _exact_sequence _ of user
interactions: chaos).

Richard.

[Elegie]

Tom Cole wrote:

Hi Tom,

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.

This means that the two requests are somehow colliding. A quick look at
your library exposed a fundamental flaw in the design, of which your
problem is likely to be a side effect.

You have defined the prototype methods right into the constructor; this
makes them instance methods of the last created instance, also
accessible to previous instances. As a result, your prototyped methods
for the first query probably use (some of) the instance variables of
your second query.

Consider the following example.

---
<script type="text/javascript">
var Foo=function(ba r){
Foo.prototype.g etBar=function( ){
return bar;
}
}

var f1=new Foo(1);
var f2=new Foo(2);
alert("f1.getBa r()="+f1.getBar ()+"\nf2.getBar ()="+f2.getBar( ));
</script>
---

I suppose you wanted to have some advanced design, properly defining
static/instance and private/public members - which is indeed the way to
go with such project. Check the following:

<URL:http://www.litotes.dem on.co.uk/js_info/private_static. html>
<URL:http://www.jibbering.c om/faq/faq_notes/closures.html>
Kind regards,
Elegie.

[Tom Cole]

On Mar 1, 9:12 am, "Richard Cornford" <Rich...@litote s.demon.co.uk>
wrote:

On Mar 1, 1:33 pm, "Tom Cole" <tco...@gmail.c omwrote:

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.
If I place either an alert between the two requests or run the second
through a setTimeout of only 1 millisecond, they both work. You can
see a working example here:http://www.lamatek.com/Ajax/test.html.

I'm hoping some of you Javascript experts can help me with why this is
happening.

Your code is written to achieve chaotic behaviour, and chaotic
behaviour is what you get. In the example page both of - r1 - and - r2
- share the same function object as their - doTextRequest - method,
and that method only has the ability to reference a single copy of the
closure formed when - r2 - is instantiated.

Superficially your problem is assigning function objects to properties
of the prototype of AjaxRequest. These function objects cause a
closure to be created, but the closure in use changes whenever a new
AjaxRequest is created, and all pre-existing AjaxRequest instances
find their methods attached to the last closure formed.

Sharing that 1st closure produces the symptoms you describe, as the
second request effectively replaces the object assigned to - xmlhttp -
with the last request made. The chaos comes in because if you made a
first request, instantiated a new AjaxRequest object and then made a
second request (even through any pre-existing AjaxRequest object) you
would not get the collision (as it would be operating in a now
abandoned closure), but a third request made before the completion of
the second and your are back to where you started. Thus you have
behaviour varying with how your code is used (and so if triggered by
user interaction, behaviour depending on the _exact_sequence _ of user
interactions: chaos).

Richard.

Not that I understand everything you said, but this is part of what my
concern was, that my methods were not unique to each instance of an
AjaxRequest.

Understanding that the type of behaviour denoted on the test page is
what I'm trying to achieve (being able to create multiple AjaxRequest
objects and have their processes run at the same time) what changes
can I make to the AjaxRequest object and it's method declarations to
make it work properly?

I'm a java developer and therefore this prototype style of inheritance
confuses me a bit.

[Tom Cole]

On Mar 1, 9:22 am, Elegie <ele...@invalid .comwrote:

Tom Cole wrote:

Hi Tom,

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.

This means that the two requests are somehow colliding. A quick look at
your library exposed a fundamental flaw in the design, of which your
problem is likely to be a side effect.

You have defined the prototype methods right into the constructor; this
makes them instance methods of the last created instance, also
accessible to previous instances. As a result, your prototyped methods
for the first query probably use (some of) the instance variables of
your second query.

Consider the following example.

---
<script type="text/javascript">
var Foo=function(ba r){
Foo.prototype.g etBar=function( ){
return bar;
}

}

var f1=new Foo(1);
var f2=new Foo(2);
alert("f1.getBa r()="+f1.getBar ()+"\nf2.getBar ()="+f2.getBar( ));
</script>
---

I suppose you wanted to have some advanced design, properly defining
static/instance and private/public members - which is indeed the way to
go with such project. Check the following:

<URL:http://www.litotes.dem on.co.uk/js_info/private_static. html>
<URL:http://www.jibbering.c om/faq/faq_notes/closures.html>

Kind regards,
Elegie.

Ahhh, "I see" said the blind man. I'm starting to get it. I noticed
that if I either:

1. Replace 'AjaxRequest.pr ototype' with 'this'
or
2. Move the prototype methods outside the AjaxRequest function

I get more like what I expected.

Thank you very much. Maybe someday I'll actually be able to code a
decent Javascript block. :)

[Richard Cornford]

On Mar 1, 2:25 pm, Tom Cole wrote:

>On Mar 1, 1:33 pm, Tom Cole wrote:

<snip>

Not that I understand everything you said,

Some of it was maybe not that clearly expressed.

but this is part of what my concern was, that my
methods were not unique to each instance of an
AjaxRequest.

But mostly you do not want methods to be unique to each instance of a
javascript object. The only methods (or, the only function objects
acting as methods) that you want to be unique are the ones that
absolutely must be unique to achieve the desired goal.

Understanding that the type of behaviour denoted on the test
page is what I'm trying to achieve (being able to create
multiple AjaxRequest objects and have their processes run at
the same time) what changes can I make to the AjaxRequest
object and it's method declarations to make it work properly?

What are you asking for? A course on the more advanced aspects of
javascript code design or me re-writing your code for you?

I'm a java developer and therefore this prototype style of
inheritance confuses me a bit.

You haven't got to inheritance yet, you are still apparently
misconceiving the role of prototypes in defining objects.

Richard.

[VK]

On Mar 1, 4:33 pm, "Tom Cole" <tco...@gmail.c omwrote:

I'm working on a small Ajax request library to simplify some tasks
that I will be taking on shortly. For the most part everything works
fine, however I seem to have some issues when running two requests at
the same time. The first one stops execution as the second continues.
If I place either an alert between the two requests or run the second
through a setTimeout of only 1 millisecond, they both work. You can
see a working example here:http://www.lamatek.com/Ajax/test.html.

Richard Cornford and Elegie already hinted you to the base of the
problem. I have - possibly bad - habit to try to explain some
javascript issues to Java/C++ people by using classy terms. Surely it
may be considered as getting a foreign joke from a word-by-word ruby
translation :-) but it also may work better than some abstract
explanations.

AjaxRequest.pro totype.doTextRe quest = function(){//...
};

is round around as

public class AjaxRequest {
public static void doTextRequest() {
// ...
}
}

here is where you are getting problems with two concurrent calls. Also
please note that in initiateRequest your variable "type" is declared
without var so created as global variable and not as local withing the
function scope. It may be what you wanted - I did not study the whole
code - but it's worth to mention.

For a good sample of AJAX library with multi-threaded request and
request grouping capabilities I suggest to take a look at AjaxRequest
<http://www.ajaxtoolbox .com>

[Richard Cornford]

On Mar 1, 5:14 pm, VK wrote:

On Mar 1, 4:33 pm, "Tom Cole" <tco...@gmail.c omwrote:

<snip>

Richard Cornford and Elegie already hinted you to the base of the
problem. I have - possibly bad - habit to try to explain some
javascript issues to Java/C++ people by using classy terms.

Your bad habit is trying to impress people who don't know any better.
As to "classy terms", you have made it abundantly clear in the past
that you have no understanding of class-based languages and the
meaning of the terminology used to talk about them.

Surely it may be considered as getting a foreign joke from a
word-by-word ruby translation :-) but it also may work better
than some abstract explanations.

Making misleading suggestions to people will nerve "work better" when
the desire is to promote understanding.

AjaxRequest.pro totype.doTextRe quest = function(){//...

};

is round around as

public class AjaxRequest {
public static void doTextRequest() {
// ...
}

Assigning function objects to the properties of a constructor's
prototype is conceptually equivalent to defining an instance method in
class-based languages (the - this - keyword - in such methods is
expected to be employed to refer to the object instance).

here is where you are getting problems with two concurrent calls.

As the master of chaotic script authoring you are unlikely to
understand, but the problem has nothing to do with your notion that
the methods assigned as properties of a prototype must be 'static'
because there is only one function object representing each. In the
code each invocation of the constructor creates a unique set of
function objects for each object instance; it just puts them where
they will be shared by all existing instances (and denies access to
the previous set at the same time).

Also please note that in initiateRequest your variable "type" is
declared without var so created as global variable and not as local
withing the function scope.

So you did not notice, or did not recognise, the closure formed with
the constructor, and its declaration of - var type = "text"; -?

It may be what you wanted - I did not study the whole
code - but it's worth to mention.

You could not have understood the code even if you had studied it.

For a good sample of AJAX library with multi-threaded request and
request grouping capabilities I suggest to take a look at AjaxRequest

<snip>

It is a better example, but still not good (particularly in its
needless use of excessive inner functions).

Richard.

[VK]

On Mar 1, 8:46 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>

Your bad habit is trying to impress people who don't know any better.
As to "classy terms", you have made it abundantly clear in the past
that you have no understanding of class-based languages and the
meaning of the terminology used to talk about them.

Yes, I know your personal position that JavaScript is so utterly
complicated and foreign to any other language that any explanations
can be given only by Books of ECMA and God forbid to make any
analogies with any other language. Let's say I listened your
argumentation in full but prefer to remain in my own opinion.

In the posed question let's also keep two defferent things separated:
prototype inheritance and scope manipulations using closures. In my
"prototype ~ static" analogy I was talking about the prototype
inheritance alone. And the prototype inheritance would be more
correctly called "prototype borrowing" because instances to not get
any ownership of methods in the prototype chain. But at the moment of
the creation they get informed where to "borrow" the needed method for
the execution time. [this] inside of the shared method is being set to
the "borrower" for the time of the execution making possible this type
of inheritance - indeed fancy thought - to work. This way
MyObject.protot ype.myMethod = function(){}
is kind of an "automated" way of

function foo() {
}

function MyObject() {
this.myMethod = foo;
}

In either case we are getting a single method allocation being used by
all instances. This is why - with all important and not so important
differences - static method in Java is the closest equivalent.

[Richard Cornford]

On Mar 1, 6:22 pm, "VK" <schools_r...@y ahoo.comwrote:

On Mar 1, 8:46 pm, "Richard Cornford" <Rich...@litote s.demon.co.uk>

>Your bad habit is trying to impress people who don't know any
better. As to "classy terms", you have made it abundantly
clear in the past that you have no understanding of
class-based languages and the meaning of the terminology
used to talk about them.

Yes, I know your personal position that JavaScript is so utterly
complicated and foreign to any other language that any explanations
can be given only by Books of ECMA and God forbid to make any
analogies with any other language.

Nonsense, I have a long record of supporting the use of terminology
from class-based languages when talking about concepts that are
analogous in javascript.

Let's say I listened your argumentation in full but prefer
to remain in my own opinion.

Let's say you do not understand what I am talking about and rather
than admitting that you would prefer to ignore me.

In the posed question let's also keep two defferent things
separated: prototype inheritance and scope manipulations
using closures. In my "prototype ~ static" analogy I was
talking about the prototype inheritance alone.

And that is where you are wrong. The appropriate concept for the act
of assigning a reference to a function object to a property of a
constructor's prototype is the defining of an instance method. All
objects created with the constructor inherit that method, and in that
method the - this - keyword can be used to refer to the object
instances. The methods are "of the class instances" not "of the
class", and so are not analogous to "static" in Java.

And the prototype inheritance would be more
correctly called "prototype borrowing" because instances
to not get any ownership of methods in the prototype chain.

Twit.

But at the moment of
the creation they get informed where to "borrow" the needed method for
the execution time. [this] inside of the shared method is being set to
the "borrower" for the time of the execution making possible this type
of inheritance - indeed fancy thought - to work. This way
MyObject.protot ype.myMethod = function(){}
is kind of an "automated" way of

function foo() {
}

function MyObject() {
this.myMethod = foo;
}

In either case we are getting a single method allocation being
used by all instances.

Having a single function object instance shared between all instances
of a 'class' is not at all a bad thing. It is certainly much more
efficient that creating a new function object to act as a method for
each instance of a class (leaving that second approach to only be
employed when the unique identity of such function objects brings with
it direct benefits).

The number of function objects being employed has little relevant to
the applicability of 'static' to instance method definitions in
javascript. In Java there is no concrete manifestation of a method;
they are not objects in their own right. But the probability is that
each and every instance of a class is executing a single copy of the
byte-code that represents one of its instance methods (or the compiled
to machine code equivalent). So were the nearest manifestation of a
method in Java is the bytes of executable code in a computer's memory
the fact that all instances of a class will share that same code can
be regarded as exactly as significant as all instances of a javascript
'class' sharing a single function object.

This is why - with all important and not so important
differences - static method in Java is the closest equivalent.

The javascript structures that are analogous to static methods in Java
are methods of the constructor and closure-contained functions that
are accessible to all instances of a class but inaccessible to any
other code (public static and private static respectively). Such
constructs are very obviously "of the class", indeed the methods of
the constructor refer to the constructor function object with the -
this - keyword. Trying to attach the term "static" to any other
structures (particularly instance methods) is only going to confuse.

Richard.