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.
