By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
432,069 Members | 1,716 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 432,069 IT Pros & Developers. It's quick & easy.

Question about Javascript classes and execution

P: n/a
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.

Mar 1 '07 #1
Share this Question
Share on Google+
18 Replies


P: n/a
On Mar 1, 1:33 pm, "Tom Cole" <tco...@gmail.comwrote:
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.

Mar 1 '07 #2

P: n/a
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(bar){
Foo.prototype.getBar=function(){
return bar;
}
}

var f1=new Foo(1);
var f2=new Foo(2);
alert("f1.getBar()="+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.demon.co.uk/js_info/private_static.html>
<URL:http://www.jibbering.com/faq/faq_notes/closures.html>
Kind regards,
Elegie.
Mar 1 '07 #3

P: n/a
On Mar 1, 9:12 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
On Mar 1, 1:33 pm, "Tom Cole" <tco...@gmail.comwrote:
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.

Mar 1 '07 #4

P: n/a
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(bar){
Foo.prototype.getBar=function(){
return bar;
}

}

var f1=new Foo(1);
var f2=new Foo(2);
alert("f1.getBar()="+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.demon.co.uk/js_info/private_static.html>
<URL:http://www.jibbering.com/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.prototype' 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. :)

Mar 1 '07 #5

P: n/a
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.

Mar 1 '07 #6

P: n/a
VK
On Mar 1, 4:33 pm, "Tom Cole" <tco...@gmail.comwrote:
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.prototype.doTextRequest = 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>

Mar 1 '07 #7

P: n/a
On Mar 1, 5:14 pm, VK wrote:
On Mar 1, 4:33 pm, "Tom Cole" <tco...@gmail.comwrote:
<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.prototype.doTextRequest = 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.
Mar 1 '07 #8

P: n/a
VK
On Mar 1, 8:46 pm, "Richard Cornford" <Rich...@litotes.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.prototype.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.

Mar 1 '07 #9

P: n/a
VK wrote:

Hi VK,
AjaxRequest.prototype.doTextRequest = function(){//...
};

is round around as

public class AjaxRequest {
public static void doTextRequest() {
// ...
}
}
What a dangerous comparison! In the programming field, 'static' has a
very well known meaning, and using some other meaning to describe a
programming issue is likely to confuse people familiar with the
technical one.

Strictly speaking, working with your example, the javascript equivalent
for some public static member would be:

---
function AjaxRequest() {}
AjaxRequest.doTextRequest = function() {}
---

The javascript equivalent for some private static member would be:

---
var AjaxRequest=(function(){
function doTextRequest(){}
return function(){}
})();
---

The prototype chain is really just an inheritance scheme. Static
members, by nature, really have nothing to do with instances, they
simply are members attached to a particular namespace, with its own
access restrictions/rules.
Kind regards,
Elegie.
Mar 1 '07 #10

P: n/a
On Mar 1, 6:22 pm, "VK" <schools_r...@yahoo.comwrote:
On Mar 1, 8:46 pm, "Richard Cornford" <Rich...@litotes.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.prototype.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.

Mar 1 '07 #11

P: n/a
VK
On Mar 1, 9:53 pm, Elegie <ele...@invalid.comwrote:
What a dangerous comparison! In the programming field, 'static' has a
very well known meaning, and using some other meaning to describe a
programming issue is likely to confuse people familiar with the
technical one.
By taking this argument just one step further we have to say that
"variable" term should not be used in explanations: otherwise C++
programmers make decide that
var i = 0;
is just like
unsigned int = 0;
or something like that :-)

There is no need for an _absolute_ equivalent to make an analogy.
Noreover an absolute equivalent is too much of a rare bird, there are
almost always some differences. One must to see behind all
differences some common structural ideas.

As an exercise one with Java knowledge may try to write a class having
the functionality similar - OK to be not equal - to

function MyObject(){}

MyObject.prototype.myMethod = function() {
return arguments.callee.marker;
}

MyObject.prototype.myMethod.marker = 'marker';

var objOne = new MyObject;
var objTwo = new MyObject;

alert( objOne.myMethod() );
alert( objTwo.myMethod() );

Mar 1 '07 #12

P: n/a
VK
On Mar 1, 9:53 pm, Elegie <ele...@invalid.comwrote:
In the programming field, 'static' has a
very well known meaning
As a side note: in the programming field "static" has different
meanings depending on the language. This is why I always saying
"static in Java/C++ sense" so do not be taken for say static modifier
in VB/VBA where it has totally different effect.

Mar 1 '07 #13

P: n/a
VK
On Mar 1, 9:54 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
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.
And that is where you are wrong. :-) By defining a prototype method
you do not affect on instance state: they do not get any new
properties and do not take any more memory than before. But if they
cannot find the requested method in within themselves then they will
find it in the prototype chain - which is the "class" structure in
JavaScript - so they will "borrow" the needed method for the execution
time.

It seems to me that both yours and Elegie arguments are based on the
idea that the function-constructor is the "class"-like structure in
JavaScript and that
MyCObject.prototype.myMethod = function(){}
is somehow related with MyConstructor prototype. It is not, and the
"class" is not MyConstructor but the immutable prototype chain created
for each instance on new MyObject; call

I invite once again to read the article at
<http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx>
Mar 1 '07 #14

P: n/a
VK
On Mar 1, 10:57 pm, "VK" <schools_r...@yahoo.comwrote:
MyCObject.prototype.myMethod = function(){}
is somehow related with MyConstructor prototype. It is not, and the
"class" is not MyConstructor but the immutable prototype chain created
for each instance on new MyObject; call
A copy'n'paste quirk. Corrected:

....
MyObject.prototype.myMethod = function(){}
is somehow related with MyObject prototype. It is not, and the
"class" is not MyObject but the immutable prototype chain created
for each instance on new MyObject; call
....

Mar 1 '07 #15

P: n/a
VK wrote:
On Mar 1, 9:54 pm, Richard Cornford wrote:
>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.

And that is where you are wrong. :-) By defining a prototype
method you do not affect on instance state:
That is absolutely, and very obviously, not true. If you do:-

function AnObject(){
;
}

var objInstance = new AnObject();

- and then:-

objInstance.someMethod();

- you get a runtime error, while if you do:-

function AnObject(){
;
}
AnObject.prototype.someMethod = function(){
;
};
var objInstance = new AnObject();

- and then:-

objInstance.someMethod();

- you do not get a runtime error. The state of the object instance
certainly has been changed, from one where it does not have a -
someMethod - method to one where it has. The assignment to the
property of the prototype has acted to define a method for instances
of - AnObject -.
they do not get any new properties
That is an insignificant detail that follows from the nature of the
language (and its prototype based inheritance). The instances behave
as if they have all the properties defined on the objects on their
prototype chain. And as javascript is not a class-based language any
attempt to describe its behaviour with the terminology from class-
based languages is tied very closely to the actual behaviour of the
objects created not the details of how they achieve that behaviour.
and do not take any more memory than before.
So what? Not needlessly consuming memory while achieving useful
behaviour is a good idea.
But if they cannot find the requested method in within
themselves then they will find it in the prototype chain -
The objects that represent the concept of an instance of a class
inherit those properties through their prototype chain. It is not
significant to the concept of an instance of a class whether it
acquired a method definition, or any other member, via inheritance or
not. The instance either has the method/member or it does not, and in
javascript if it is on the object's prototype chain the object will
behave as if it has the method/member.
which is the "class" structure in JavaScript -
No it is not. The prototype chain is the inheritance mechanism. The
class definition is the totality of the code that influences the
structure and behaviour of objects that are intended to act as
instances of that 'class'.
so they will "borrow" the needed method for the execution
time.
It is stupid to attempt to replace the word 'inherit' with "borrow".
Apart from leaving you talking a completely different language to
everyone else (which is hardly new for you), it does not take into
account that assigning an instance of 'superclass' to the prototype of
a constructor that is to act as a 'subclass' is a normal strategy for
extending a 'class' when working with javascript. The instances of the
'subclass' then inherit the instance methods of the 'superclass' from
the prototype of their prototype. It would make as little sense to
describe that as "borrowing" as it would to describe a Java class
extending a superclass as "borrowing" the methods that it inherited
from its superclass.

It seems that fact that in javascript functions are objects and so
have tangible manifestations is getting in the way of your seeing how
irrelevant that is to applying the concepts from class-based OO to
javascript.

If you have:-

function forAnObjectGetState(){
return this.state;
}

function AnObject(x){
this.state = x;
this.getState = forAnObjectGetState;
}

- or:-

function AnObject(x){
this.state = x;
}
AnObject.prototype.getState = function(){
return this.state;
};

- or:-

function AnObject(x){
this.state = x;
this.getState = function(){
return this.state;
};
}

- any use of - var objInstance = new AnObject(y); - will return an
object with equivalent methods/members and resulting behaviour. In
terms of class-based OO the three class detentions are effectively
equivalent, and the object instances resulting from any of those
detentions are also equivalent. If any one satisfies the concepts from
a class based language then they all do, and to precisely the same
extent.

Of course they differ in how they are implemented in javascript; the
first needlessly pollutes the global namespace with a function that
should never be used as a global function, and adds a small overhead
on each object creation when it assigns that function to one of its
properties, the last adds a bigger overhead as it creates a new (but
otherwise indistinguishable) function object for each object
constructed. But those differences do not impact upon the instances of
the 'class' that are created with those definitions in any practical
way.

Your position is that if someone calls - objInstance.getState() - on
an object created with the first two 'class' definitions then it is a
call to a 'class method' (a "static" method), but if they perform the
same call on an object created with the final 'class' definition then
they are calling an 'instance method', regardless of the fact that
with all three definitions the - this - keyword inside the method code
refers to the object instance, and in all cases the same behaviour is
manifest, with the same outcome.

It is irrational to propose that the applicability of the terms
"static" and 'instance' relates entirely to a largely arbitrary
implementation decision. It is the role and the behaviour of the code
used that determines the extent to which terminology from class-based
languages can sensibly be applied to it.
It seems to me that both yours and Elegie arguments are based
on the idea that the function-constructor is the "class"-like
structure in JavaScript
It seems to me that once again you are incapable of recognising a
subject that is out of your league. We have ascertained in the past
that you have not practical familiarity with either Java or C++ (from
the nonsense you have posted on those subjects), and we know that your
javascript skills don't run to being able to put together a dozen
lines of functional code, so it is not surprising that once again this
has gone right over your head.
and that MyCObject.prototype.myMethod = function(){}
is somehow related with MyConstructor prototype. It is
not, and the "class" is not MyConstructor but the immutable
prototype chain created for each instance on new MyObject; call
There are no 'classes' in javascript (or there is only one class,
which would be the same thing), so when the term 'class' is applied to
a construct created with javascript it can reasonably be applied to
any construct that satisfies the concept. The prototype chain of an
object instance (or, more precisely) the code that determines the
prototype chain of that object instance) is only ever a tiny fraction
of what could qualify as a construct implementing the 'class' concept
in javascript. It is even possible for the prototype chain to play no
role at all in what could reasonable be called a 'class' definition,
and the objects created with it (thus the prototype chain cannot
represent the class definition).
I invite once again to read the article at
<http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx>
If you are going to attempt to distract attention with irrelevances I
will ask you once again whether you are ever going to actually post
your much vaunted rounding function, or are you going to finally admit
that the task is beyond you. How long has it been now since you
promises to write one that was 'better' than the one in the FAQ? And
if you cannot do it are you going to go back to those threads and
admit that your request to have the FAQ changed was based on nothing
but personal ignorance and incompetence?

Richard.

Mar 2 '07 #16

P: n/a
VK
>And that is where you are wrong. :-) By defining a prototype
>method you do not affect on instance state:
That is absolutely, and very obviously, not true.
Of course it is true. Your problem is in mixing together two very
different things: the object structure and the object behavior. By
changing the prototype we are obviously affecting on the _behavior_ of
future and current instances created with the relevant constructor: we
will be able to use new properties and methods of them. At the same
time the structure of each particular instance doesn't change for a
single byte - no matter how many times will you make assignments of a
kind MyObject.prototype.foo = bar. Equally you may do not touch
MyObject.prototype at all: and the size of each created instance will
be still the same as after N of MyObject.prototype assignments.
In any case each instance has one special field in its internal name
table: the name of the first object in the prototype chain to look for
a property or a method if not found in the own instance name table.
There is always at least one object in this chain for any instance and
this is Object.prototype
It can be as many objects as reasonably imaginable in this chain, and
each object has the same structure: names of its own properties and
methods and one special field with the next object deeper in the chain
if it's still not found what was looked for. If this is the bottom of
the chain then this field will contain undefined.

I really did so many explanations already of the prototype inheritance
that I just don't feel like to go through hasOwnProperty / in samples
and the relevant stuff once over again. It seems to me that it's
another mute point - you'll see and hear only what you want to see and
to hear.

>they do not get any new properties
That is an insignificant detail that follows from the nature of the
language (and its prototype based inheritance).
It is a very significant detail for an effective programming. The are
two points here:

1) prototype methods (~~ "static class methods") are being found by a
rather boring lookup chain:
- do you have it?
- no
- do you have anyone else to ask?
- minute... yes
- so fn ask him!
- asking...
(the conversation gets repeated one level deeper)

2) JavaScript object structure is dynamic so can be changed at any run-
time moment. This is why DispID (~ pointers) are not reusable but
being obtained over and over again by name table. That means that in
code like:
for (var i=0; i<100; i++) {
objInstance.prototypeMethodThreeLevelsDeep();
}

the "conversation" from the point (1) get repeated N_OfLevels * 100
times

This is why for the must ineffective code one is welcome to follow the
"slavery OOP" or "academic twist OOP" - call it whatever you like.
b.prototype = new a;
c.prototype = new b;
....
z.prototype = new y;

Most of practicing programmers are coming to the right conclusion
sooner or later by empirical way - like Matt Kruse already did. But
because the internal mechanics remains oftenly hidden for them, many
of them just keep thinking of it as of some bizarrity or as of some
side effect of a particular code layout.

Note: It is also explains why deep-nested namespaces are another
productivity killer for JavaScript, I mean like
we.are.doing.very.conceptual.oop.programming() and similar. The reason
why this silly fashion did not collapse so far is the tremendous
processor speed increase over the last years. Still the most "nasty
conceptualists" like MoJo seems managing to noticeably slow down even
1.x GHz machines.
>I invite once again to read the article at
<http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx>
If you are going to attempt to distract attention with irrelevances<snip>
It is not an irrelevance. This is the first necessary step to start
talking about prototype inheritance. Until the core of constructor and
prototype matters is understood properly and in full - until then
there is no use to go too deep into details.

Mar 3 '07 #17

P: n/a
"VK" <sc**********@yahoo.comwrote:
>>And that is where you are wrong. :-) By defining a
prototype method you do not affect on instance state:
>That is absolutely, and very obviously, not true.

Of course it is true.
The state of an object in javascript is partly defined by its prototype.
Your problem is in mixing together two very
different things:
I don't have a problem here at all. Remember that one of us can write
effective code using javascript, and you cannot. (And we were right not
to start holding our breath waiting for you to come up with your much
vented "rounding function" as that task clearly was beyond you (as
anticipated).)
the object structure and the object behavior.
I am not mixing them up, I am observing that only the behaviour is
significant to the applicability of the terminology form class-based
languages to constructs written in javascript. That is the case becasue
javascript is not a class-based language so the details of the structures
of objects needed to achieve any particular behaviour are consequences of
a using a functional programming language with prototype based
inheritance, and so it is the terminology of a functional programming
langue with prototype based inheritance that will appropriately describe
it.

The terminology from class-based languages can be applied, in code design
and to code written, but it applies at a level above the javascript
itself; it applies to concepts being employed, not the particular details
of their implementation.
By changing the prototype we are obviously affecting on
the _behavior_ of future and current instances created
with the relevant constructor:
Defining the nature of the objects that will be constructed.
we will be able to use new properties and methods of them.
At the same time the structure of each particular instance
doesn't change for a single byte -
So what if the structure does not change? All that means it that defining
the nature of the constructed objects with the constructor's prototype is
an efficient implementation strategy in javascript. The suitability of
describing the totality of the code that determines the nature of the
constructed object as a 'class' definition, or of the objects created as
instances of a 'class' is not changed by some author's decision to employ
any of the less efficient alternatives.

I have already demonstrated that what is effectively the same 'class'
definition may be implemented in three distinctly different ways. The
scores of alternatives, and thousands of permutations, that javascript
offers as alternative ways of achieving effectively the same outcome do
not modify the suitability of applying the 'class' concept to the end
result.
no matter how many times will you make assignments
of a kind MyObject.prototype.foo = bar.
It makes little sense to assign any value to a property of a prototype
more than once, and the runtime modification of a prototype is one of the
actions that negates the applicability of the 'class' concept (as
class-based languages do not allow the runtime modification of the class
definition).
Equally you may do not touch MyObject.prototype at all:
and the size of each created instance will be still the
same as after N of MyObject.prototype assignments.
Again, what of it?
In any case each instance has one special field in its internal
name table: the name of the first object in the prototype chain
Javascript objects do not have a "name", so no "name of the first object"
can appear in any supposed "internal name table".
to look for a property or a method if not found in the own
instance name table.
The mechanism by which a property accessor is resolved into a value has
no relevance to whether, and which, terminology from class-based
languages can or should be applied in javascript.
There is always at least one object in this chain for any
instance and this is Object.prototype
No there is not (else all prototype chains must then be infinitely long).
Object.prototype - itself has a null [[Prototype]].
It can be as many objects as reasonably imaginable in this
chain, and each object has the same structure: names of its
own properties and methods and one special field with the
next object deeper in the chain if it's still not found what
was looked for.
That is a prototype chain, and it is a very useful thing, but its use in
javascript to resolve property accessors has no bearing on the
applicability of the terminology from class-based languages. If a method
is accessed as property of an object instance the that method will behave
as if it was a method of that particular object instance regardless of
whether it was actually a property of the javascript object that is the
instance or a property of any object on its prototype chain.
If this is the bottom of the chain then this field will
contain undefined.
It is null. The [[Prototype]] property of the last object on the
prototype chain is specified as being null not undefined.
I really did so many explanations already of the prototype
inheritance that I just don't feel like to go through
hasOwnProperty / in samples and the relevant stuff once over again.
You are not seeing what is relevant here. If you were rational what you
would be doing here is attempting to justify your assertion that methods
defined on a contractor's prototype should be called "static" methods.
Nobody is disputing that those methods are not properties of the object
instances constructed, but are instead inherited by it through its
prototype chain.
It seems to me that it's another mute point - you'll see
and hear only what you want to see and to hear.
Well I do have some practical experience of authoring with class-based
languages, and have done a great deal to towards promoting the OO
application of javascript. So I ma certainly not going to see your
inconsistent and irrational ramblings are representing any sort of
contribution in this area. But more significant that what I may think is
the fact that nobody with both class-based language experience and an
understanding of javascript agrees with you. You are completely on your
own in these beliefs.
>>they do not get any new properties
>That is an insignificant detail that follows from the nature
of the language (and its prototype based inheritance).

It is a very significant detail for an effective programming.
For effective programming with javascript, but not significant to the
applicability of the term "static" to methods defined on a constructor's
prototype, which is the nonsense suggestion that you are trying to
justify here.
The are two points here:

1) prototype methods (~~ "static class methods") are being
found by a rather boring lookup chain:
<snip>

So once again, a method of an object can be called in the same way,
execute identical code, interact with that object in the same way and
produce the same outcome, but in your opinion it is conceptually a
"static" method if it is defined on th object's constructor's prototype,
but is conceptually an 'instance' method if assigned directly to the
object itself.
2) JavaScript object structure is dynamic so can be changed at
any run- time moment.
The 'class' concept borrowed from class-based languages requires that, as
in class-based languages, the structure and behaviour of the object
instances (as defined with the class definition) and the class definition
itself, is not subject to runtime modification. If you want to use
javascript's capability for runtime object modification you have stepped
outside of the 'class' concept and are working with concepts that only
exist in sufficiently dynamic languages like javascript. This makes the
runtime mutability of javascript's objects irrelevant to the
applicability of terminology from class-based languages to javascript.
This is why DispID (~ pointers) are not reusable but
being obtained over and over again by name table. That
means that in code like:
for (var i=0; i<100; i++) {
objInstance.prototypeMethodThreeLevelsDeep();
}
<snip>

Why do you always try to distract attention form you follies with forays
into the irrelevant?
>>I invite once again to read the article at
<http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx>
>If you are going to attempt to distract attention with
irrelevances<snip>

It is not an irrelevance.
<snip>

Yes it is. There is nothing in the structures of javascript or the
details of the JScript implementation that have any baring on your
irrational attempt to attach the term "static" to the structure that is
used define instance methods and default instance members in javascript.

Richard.

Mar 3 '07 #18

P: n/a
VK
On Mar 4, 1:33 am, "Richard Cornford" <Rich...@litotes.demon.co.uk>
wrote:
we were right not
to start holding our breath waiting for you to come up with your much
vented "rounding function"
<OT>
That's a good kick. I'm really glad to start working over rounding and
overall IEEE-754 issues as I got unexpected benefits for my own
studies.

But you are right that the promise has to be held. The quick answer is
that the native toFixed method is the best way to go. By desing of
IEEE-754 and JavaScript/JScript math engine anything else increases
precision loss without any benefits. That includes multiplying to 10,
100, 1000... to bring float to integer state. The deal is to normalise
toFloat of IE and toFloat on other browsers in their equipoint
treatment ("5 to 0 or to 1" on decimal). OK, I just marked it in my
scheduler with ex sign :-)
Unfortunately I have a China-made French purses database update with
two exs in front of it for Monday and I have a tradition do not do
IEEE-754 stuff on week-end, that's a bad sign :-) I'll do whatever
possible, I promise.
</OT>

Mar 3 '07 #19

This discussion thread is closed

Replies have been disabled for this discussion.