Question about Javascript classes and execution

[Richard Cornford]

Re: Question about Javascript classes and execution

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.som eMethod();

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

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

- and then:-

objInstance.som eMethod();

- 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 forAnObjectGetS tate(){
return this.state;
}

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

- or:-

function AnObject(x){
this.state = x;
}
AnObject.protot ype.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 indistinguishab le) 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.get State() - 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.proto type.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.

[VK]

Re: Question about Javascript classes and execution

>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.protot ype.foo = bar. Equally you may do not touch
MyObject.protot ype at all: and the size of each created instance will
be still the same as after N of MyObject.protot ype 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.prototyp e
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.pro totypeMethodThr eeLevelsDeep();
}

the "conversati on" 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.ve ry.conceptual.o op.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<sn ip>

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.

[Richard Cornford]

Re: Question about Javascript classes and execution

"VK" <schools_ring@y ahoo.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.protot ype.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.protot ype at all:
and the size of each created instance will be still the
same as after N of MyObject.protot ype 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.prototyp e

No there is not (else all prototype chains must then be infinitely long).
Object.prototyp e - 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.pro totypeMethodThr eeLevelsDeep();
}

<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<s nip>

>
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.

[VK]

Re: Question about Javascript classes and execution

On Mar 4, 1:33 am, "Richard Cornford" <Rich...@litote s.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>