VK said:
No, it just illustrates really well why am I having such troubles to
communicate with you and with some other regulars in this group:
Are you about to argue that you are right and everyone else is wrong,
again?
because of an extremely chaotic approach to the inheritance questions.
It is hardly anyone else's fault that you still do not understand how
inheritance works in javascript, it has been explained to you often
enough.
Depending on circumstances one either fixates on "visual difference"
(this lion is brown, this lion almost yellow, so the second one is not
lion) or on "visual similarity" (lion has a tail, tiger has a tail, so
both are the same animal).
It is hardly any one else's fault that you don't comprehend logic.
The first issue is illustrated by the
current "static" discussion; the second one leads to the non-sense like
"Array is Object, just with that funny length property added"
An array is an object, with a special [[Put]] method that modifies its
- length - property when 'array index' property names are used with it
and sometimes its 'array index' properties when the property name
'length' is used with it.
(Array is an object by it is not the Object: but it inherits from and
extends base Object constructor).
There is no sense in "inherits from and extends base Object
constructor". The constructor is a function object and Arrays do not
inherit from function objects. They inherit from the object that is the
original value of - Object.prototype -, and do so through the object
that is the value of - Array.prototype -. In a language that uses
prototype inheritance it is prototypes that are inherited from.
Without too much hope to change your mindset
Zero. You are wrong, so the only person who needs to change their mind
is you.
but to protect other potential thread readers:
You mean add to the harm you have already done with additional
misconceptions and more irrelevant misdirection?
as it was explained in my post JavaScript implements static and
per-instance methods as well as other C-languages
do -
The C language does not include static or per-instance methods (that is
what C++ adds). And javascript is not a C-language, it is a language
with a C-like syntax, but more closely related to List, Self and
Scheme.
with necessary differences implied by different inheritance
models.
I thought I provided enough of reading but you seem jumped on the
possibility to reference static methods in JavaScript by [this] keyword
Yes, that is a very significant difference between a static method and
an instance method; an instanced method may refer to its own object
instance with the - this - keyword, and a static method cannot because
being "of the class" it does not relate to any single object instance.
- as it's the core reason do not be static.
It is sufficient reason alone. It was not the only reason that I
stated.
It has nothing to do with being static or not being static.
So why is it stated as a distinction between instance methods and
static methods in both of the definitions of static that you cited?
Maybe more basic reading would help:
It might help you, though understanding the words used in what you have
read would be more useful to you.
<quote
cite="
http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html">
Class methods cannot access instance variables or instance methods
directly-they must use an object reference. Also, class methods
cannot use the this keyword as there is no instance for this to refer
to.
"Note: You can also refer to static fields with an object reference
like
myBike.numberOfBicycles
but this is discouraged because it does not make it clear that they are
class variables."
Discouraged because instance method can be referenced in the same way,
and so no distinction between the two is apparent in the code. But
being able to write:- myBike.instanceUniqueId - does not make -
instanceUniqueId - a static member just because it has the same form as
one that may be used to access a static member.
(In JavaScript case we necessarily change "class variable" to
"prototype variable" and "discouraged" has no much weight).
Prototypes, and modifications to those prototypes are used to define
and default instance variables/methods, so it would be very foolish to
use 'prototype variable' in place of 'class variable'.
<script type="text/javascript">
function C() {
this.personal = new Function;
}
C.prototype.shared = new Function;
var obj1 = new C;
var obj2 = new C;
alert(obj1.personal === obj2.personal); // false
alert(obj1.shared === obj2.shared); // true
alert(obj1.hasOwnProperty('personal')); // true
alert(obj1.hasOwnProperty('shared')); // false
</script>
Again you post code with no explanation of what you think it is
supposed to be demonstrating. (If you are going to complain that you
have trouble communicating maybe you should consider that your failure
to explain code that you post as 'examples', and for that matter your
failure to answer any of the questions you are directly asked, might
significantly contribute to that.)
You are letting the identity of function objects confuse you about the
roles and status of the methods used here. All of the method assigned
are instance methods (regardless of the number of function objects used
to implement each). You can tell that they are instance methods because
in each the - this - keyword can be used to reference the individual
object instances.
A simpler distinction between static and instance may be demonstrated
with a non-method property. If such a property was static then its
single value would be shared by all instances of a class, and all
instances of that class could modify the value, resulting in all
instances of the class seeing the modified value.
So if you define a property on a prototype, as:-
function AnObject(){
;
}
AnObject.prototype.someValue = 5;
- and create two instances of AnObject:-
var a = new AnObject();
var b = new AnObject();
- reading the value of - someValue - will return the default value
defined by the assignment to the prototype's property:-
alert(a.someValue); // alerts 5
alert(b.someValue); // alerts 5
Now if - someValue - as a static member of the class (a 'class
variable') an assignment of a new value to - someValue - from any
instance would modify the results obtained from reading the property
from all instances. So:-
a.someValue = 8;
- would result in instance b alerting 8 from:-
alert(b.someValue);
- but it still alerts 5. The - someValue - properties of the object
instances are instance variables, they just have default values that
they inherit from a prototype (and because the prototype is dynamic the
default value may be subject to runtime modification).
In javascript it is completely feasible to create variables and methods
that are static (are "of the class") and that work in a way that
satisfies the concept of 'static' as it is used in class-based
languages, but the properties of the prototype are not capable of
satisfying that role.
Richard.