«

Richard Cornford wrote:
> It is precisely your pose, and specifically where you characterise
> instance methods inherited through the prototype as "static", that makes
> it obvious that you do not comprehend the concept of 'static' as it used
> in class-based languages:-

No, it just illustrates really well why am I having such troubles to
communicate with you and with some other regulars in this group:
because of an extremely chaotic approach to the inheritance questions.
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). 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" (Array is
an object by it is not the Object: but it inherits from and extends
base Object constructor).

Without too much hope to change your mindset but to protect other
potential thread readers: as it was explained in my post JavaScript
implements static and per-instance methods as well as other C-languages
do - 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
- as it's the core reason do not be static. It has nothing to do with
being static or not being static. Maybe more basic reading would help:
<http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html>
"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."

(In JavaScript case we necessarily change "class variable" to
"prototype variable" and "discouraged" has no much weight).

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

VK wrote:
> Richard Cornford wrote:
>> It is precisely your pose, and specifically where you characterise
>> instance methods inherited through the prototype as "static", that
>> makes it obvious that you do not comprehend the concept of 'static'
>> as it used in class-based languages:-
>
> 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.

> <http://java.sun.com/docs/books/tutorial/java/javaOO/classvars.html>

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

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

> I personally prefer method 1 since it seems to allow a notion of public
> and private members. For example,
>
> function myclass() {
> var privateVar = "hi"
> function privateFn() { return privateVar }
> this.publicFn = function() { return privateFn() }
> }

As explained in my previous post, it is irrelevant whether you need an
emulation of protected scope for your method or not; what is relevant
is whether you need per-instance protected scope or just one protected
scope for all instances (so their getter/setter methods will work on
competition basis). The latter is rather dangerous doing because
JavaScript doesn't have synchronized modifier so the execution flow can
get really fancy In any case it is yours to decide.

1) Per-Instance protected scope (string variable in this sample)

<script type="text/javascript">
function MyObject(arg) {
// Overriding toString method to prevent
// source dump. This method is static so
// shared by constructor and all instances:
this.toString = MyObject.toString;
// Create instance-specific protected scope
// and provide getter/setter accessors to the
// current instance:
ProtectedScope.call(this, arg);
function ProtectedScope(arg) {
this.getPrivate = getPrivate;
this.setPrivate = setPrivate;
var $default = 'foo';
var $private = (typeof arg == 'string') ? arg : $default;
function getPrivate() {
return $private;
}
function setPrivate(arg) {
$private = (typeof arg == 'string') ? arg : $default;
}
}
}
MyObject.toString = function() {
return 'function';
// ... or some bogus function body code
}

var obj1 = new MyObject('foobar');
var obj2 = new MyObject;
obj1.setPrivate('bar');
alert(obj1.getPrivate()); // 'bar'
alert(obj2.getPrivate()); // 'foo' (default)
</script>

There is few catches in here.
First of all, inner functions (inner classes in some other languages)
is what is called "undocumented language feature". It is entirely based
on the fact that any good written engine will try to interpret any code
as long as it's syntactically correct. At the same time while making
the original JavaScript specs no one in the wildest dream wouldn't
imagine a code like function a(){function b(){function c(){}}} not only
being used - but being nearly a core of many solutions. It doesn't mean
do not use it: but it means use with care and check every outcome on
every engine of your interest.

Secondly, as Jonas Raoni already pointed out, regular JavaScript
doesn't have private or protected modifiers. So the max one can do is
to emulate it by carefully applying closure mechanics. In the sample
above despite "visually" we are dealing with the same inner function
ProtectedScope, in fact we are forming new closure (thus separate
scope) for each object instance.

AFAICT Cornford-Crockford (CC) scope management doesn't allow purely
static protected members: that is an implication of a solution based on
closures. The max you can do is to have static compound property
("protected variable" in CC) which is shared among all class
instances: but getter/setter for this property ("privileged methods" in
CC) will be individually cloned for each class instance.

P.S. "class instance" term is used in application to the objects
produced by function-constructor.

Richard Cornford wrote:
> 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).

Are you kidding me or is it a "straw man" tactics? On property access
request the property is first searched in the object instance, if not
found (and only if not found) it is searched along the inheritance
chain (from prototype to prototype). Originally "a" doesn't have
someValue property, so the engine looks for it in the prototype. Then
you create someValue property with value 8 so the engine doesn't look
for it anymore in the prototype: but the prototype value itself doesn't
change and it doesn't disappear. In the programming it is called
"shadow something".

Respectively all other instances do not have the inherited value
shadowed by own property.

<script type="text/javascript">
function C() {
;
}
C.prototype.n = 5;

var obj = new C;
alert(obj.n); // 5
alert(obj.hasOwnProperty('n')); // false
obj.n = 8;
alert(obj.n); // 8
alert(obj.hasOwnProperty('n')); // true
alert(obj.constructor.prototype.n); // 5
</script>

VK wrote:
> On property access
> request the property is first searched in the object instance, if not
> found (and only if not found) it is searched along the inheritance
> chain (from prototype to prototype). Originally "a" doesn't have
> someValue property, so the engine looks for it in the prototype. Then
> you create someValue property with value 8 so the engine doesn't look
> for it anymore in the prototype: but the prototype value itself doesn't
> change and it doesn't disappear. In the programming it is called
> "shadow something".
>
> Respectively all other instances do not have the inherited value
> shadowed by own property.
>
> <script type="text/javascript">
> function C() {
> ;
> }
> C.prototype.n = 5;
>
> var obj = new C;
> alert(obj.n); // 5
> alert(obj.hasOwnProperty('n')); // false
> obj.n = 8;
> alert(obj.n); // 8
> alert(obj.hasOwnProperty('n')); // true
> alert(obj.constructor.prototype.n); // 5
> </script>

Respectively to change a static property you have to *change* that
property, not *shadow* it in selected instances:

<script type="text/javascript">
function C(){
;
}
C.prototype.n = 5;

var obj1 = new C;
var obj2 = new C;
alert(obj1.n); // 5
alert(obj2.n); // 5
obj1.constructor.prototype.n = 8;
alert(obj1.n); // 8
alert(obj2.n); // 8
</script>

P.S. OT: I'm an IQ monster At 5am I'm eating an open face turkey
sandwich by one hand and explaining JavaScript inheritance by other
hand. I'm ready to be an astranaute I guess

VK wrote:

> [...]
> function ProtectedScope(arg) {
> this.getPrivate = getPrivate;
> this.setPrivate = setPrivate;
> var $default = 'foo';
> var $private = (typeof arg == 'string') ? arg : $default;
> function getPrivate() {
> return $private;
> }
> function setPrivate(arg) {
> $private = (typeof arg == 'string') ? arg : $default;
> [...]

Any reason for the sigils, or just personal preference ?

--
Bart

VK wrote:
> > I personally prefer method 1 since it seems to allow a notion of public
> > and private members. For example,
> >
> > function myclass() {
> > var privateVar = "hi"
> > function privateFn() { return privateVar }
> > this.publicFn = function() { return privateFn() }
> > }
>
> As explained in my previous post,

LOL

> it is irrelevant whether you need an emulation of protected scope
> for your method or not; what is relevant is whether you need
> per-instance protected scope or just one protected scope for
> all instances (so their getter/setter methods will work on
> competition basis).

Don't be silly, if no emulation of protected members is necessary it
don't matter at all whether they are not instance members or not class
members.

> The latter is rather dangerous doing because
> JavaScript doesn't have synchronized modifier so the execution flow can
> get really fancy

Javascript is single threaded so it does not need any synchronisation
mechanism.

> In any case it is yours to decide.
>
> 1) Per-Instance protected scope (string variable in this sample)

The code you post is usually illustrative of the consequences of your
legion misconceptions about javascript.

> <script type="text/javascript">
> function MyObject(arg) {
> // Overriding toString method to prevent
> // source dump. This method is static so
> // shared by constructor and all instances:
> this.toString = MyObject.toString;

This is pointless and your justification is bogus and dishonest, as the
- toString - method inherited from the original - Object.prototype -
returns "[object Object]", which is hardly something that represents a
"source dump".

> // Create instance-specific protected scope
> // and provide getter/setter accessors to the
> // current instance:
> ProtectedScope.call(this, arg);
> function ProtectedScope(arg) {
> this.getPrivate = getPrivate;
> this.setPrivate = setPrivate;
> var $default = 'foo';
> var $private = (typeof arg == 'string') ? arg : $default;
> function getPrivate() {
> return $private;
> }
> function setPrivate(arg) {
> $private = (typeof arg == 'string') ? arg : $default;
> }
> }
> }
> MyObject.toString = function() {
> return 'function';
> // ... or some bogus function body code
> }

This is pretty much pointless as if other code wanted to get a string
represen5taion of the constructor's source (which is pretty pointless
itself) it only has to delete the - toString - property of this object
to re-expose the original - Function.prototype.toString -
value,directly assign that value to the - toString - property of this
object (overwriting this method), or use the - apply - or - call -
methods of the original - Function.prototype.toString - method.

Now let's see that code implemented without the obfuscating
convolutions and utterly pointless actions:-

function AnObject(arg){
var value = (typeof arg == 'string')? arg:'foo';
this.getPrivate = function(){
return value;
};
this.setPrivate = function(v){
value = (typeof v == 'string')? v:'foo';
};
}
AnObject.toString = function(){
return 'function';
};

- Now isn't that considerably simpler and clearer? (and inevitably much
more efficient as well).

> var obj1 = new MyObject('foobar');
> var obj2 = new MyObject;
> obj1.setPrivate('bar');
> alert(obj1.getPrivate()); // 'bar'
> alert(obj2.getPrivate()); // 'foo' (default)
> </script>
>
> There is few catches in here.
> First of all, inner functions (inner classes in some other languages)
> is what is called "undocumented language feature".

Nonsense. Inner functions are a fully specified feature of all ECMA
262, 3rd edition implementations.

> It is entirely based on the fact that any good written engine will try
> to interpret any code as long as it's syntactically correct.

It is completely based upon a formal language specification.

> At the same time while making
> the original JavaScript specs no one in the wildest dream wouldn't
> imagine a code like function a(){function b(){function c(){}}} not only
> being used - but being nearly a core of many solutions.

If that were true the specification would not tell you precisely how
that code is to be interpreted and executed in precise detail, which it
does.

The limitation you are describing here is yours. You cannot comprehend
the specification so you assume that what you do not perceive in it is
not there. In reality ECMA 262 states precisely how any syntactically
correct javascript source code permutation that can be created will be
executed. That is, after all, what a computer language specification
must do in order that it may be implemented.

> It doesn't mean do not use it: but it means use with care and
> check every outcome on every engine of your interest.

Nonsense.

> Secondly, as Jonas Raoni already pointed out, regular JavaScript
> doesn't have private or protected modifiers. So the max one can do is
> to emulate it by carefully applying closure mechanics. In the sample
> above despite "visually" we are dealing with the same inner function
> ProtectedScope, in fact we are forming new closure (thus separate
> scope) for each object instance.

And doing so in a pointlessly convoluted way.

> AFAICT Cornford-Crockford (CC) scope management doesn't allow
> purely static protected members:

The list of things you cannot tell about javascript is extensive.

> that is an implication of a solution based on
> closures. The max you can do is to have static compound property
> ("protected variable" in CC) which is shared among all class
> instances: but getter/setter for this property ("privileged methods" in
> CC) will be individually cloned for each class instance.
<snip>
Nonsense.

Richard.

Bart Van der Donck wrote:
> > $private = (typeof arg == 'string') ? arg : $default;
>
> Any reason for the sigils, or just personal preference ?

The sigil itself in "tentatively private member" name is for more easy
"visual" code navigation between the team members plus for automated
POD generation (Hungarian notation would be way too "heavy" for
JavaScript).
"$" for sigil instead of say underscore is a personal preference (a
subconscious Perl influence maybe

VK wrote:
<snip>
> Are you kidding me or is it a "straw man" tactics?

I am showing you that prototypes are used for defaulting instance
variables and methods and have no relationship with concepts behind the
use of the term 'static' in class-based languages. Regardless of the
fact that there is only ever a single default value that single value
is not conceptualy "of the class", it is a default for the instance.

Richard.

VK wrote:
> Richard Cornford wrote:
> > I am showing you that prototypes are used for defaulting instance
> > variables and methods and have no relationship with concepts behind the
> > use of the term 'static' in class-based languages. Regardless of the
> > fact that there is only ever a single default value that single value
> > is not conceptualy "of the class", it is a default for the instance.
>
> Well, if you are serious in what you are saying then your perception of
> JavaScript and especially its inheritance is seriously damaged.

As if you could tell.

> <script type="text/javascript">
> function C() {
> ;
> }
> C.prototype.n = 5;
>
> var obj = new C;
>
> alert(obj.n); // 5
>
> // n is not own instance property,

It looks like you are referencing it as a property of an instance to
me.

> it is
> // static property provided through the
> // prototype inheritance:

It is an instance property defaulted though inheritance from the
prototype.

> alert(obj.hasOwnProperty('n')); // false
>
> // shadow inherited property by own property
> // with the same name:
> obj.n = 8;
> alert(obj.n); // 8
> // this n is own instance property
> // but it has nothing to do with the
> // inherited static property n:
> alert(obj.hasOwnProperty('n')); // true

The actual value of the instance property is now held on the object
instance itself rather than being inherited from the prototype. That is
the nature of javascript's inheritance.

> // inherited property itself is still there
> // but it's shadowed by instance's own property:
> alert(obj.constructor.prototype.n); // 5
>
> // remove the own property shadowing
> // the inherited one:
> delete obj.n;
>
> // inherited property is visible again:
> alert(obj.n); // 5
> alert(obj.hasOwnProperty('n')); // false
> </script>

You are still fixating on the singleness of the values stored on the
prototype as indicating that they are 'static'. That singleness is
irrelevant to the concept of static in class-based languages, it is
just a feature of how javascript's object instances are defined.

A simple parallel can be found in Java's class definitions. When you
declare an instance member you can default its value, and all instances
will then have that value until they assign a new value to that member
(or a new value is assigned from outside, if possible). Nobody would
consider those default values 'static' and they are certainly not
declared as such.

Javascript is not a class-based language and has no modifiers, but if
the terminology from class-based languages is going to be applied to
its constructs they should be applied where javascript constructs
parallel the concepts being spoken off.

The mechanism that defaults the values of object instance members is
not a suitable target for the term 'static', and it is not a term that
applies to parallel mechanisms in class-based languages. The fact that
the values that are used to default are singular is just a feature of
that mechanism, and has no significance beyond that.

As with class-based languages, the features of javascript that may
reasonable be termed 'static' are those that relate to the class. They
are most often manifest in the notion of 'public static' members, being
properties of the constructor function. Such properties satisfy every
aspect of the definitions of 'static' that you have posted references
to, and being properties of the constructor they are referenced in a
way that makes it obvious that they relate to the class as a whole and
not its instances.

> P.S. Which is a proof that despite your own many times stated believe
> it is possible to write working sophisticated programs even with
> serious misconceptions about the used language

Is it? Where is this "sophisticated program" then?

Richard.