defining classes-- different methods

[Bart Van der Donck]

Re: defining classes-- different methods

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

[Richard Cornford]

Re: defining classes-- different methods

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.toStri ng;

This is pointless and your justification is bogus and dishonest, as the
- toString - method inherited from the original - Object.prototyp e -
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.toStri ng = 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.protot ype.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.protot ype.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.toStri ng = function(){
return 'function';
};

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

var obj1 = new MyObject('fooba r');
var obj2 = new MyObject;
obj1.setPrivate ('bar');
alert(obj1.getP rivate()); // 'bar'
alert(obj2.getP rivate()); // 'foo' (default)
</script>
>
There is few catches in here.
First of all, inner functions (inner classes in some other languages)
is what is called "undocument ed 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.

[VK]

Re: defining classes-- different methods


Bart Van der Donck wrote:

$private = (typeof arg == 'string') ? arg : $default;

>
Any reason for the sigils, or just personal preference ?

The sigil itself in "tentativel y 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 :-)

[Richard Cornford]

Re: defining classes-- different methods

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]

Re: defining classes-- different methods


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.

<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 is
// static property provided through the
// prototype inheritance:
alert(obj.hasOw nProperty('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.hasOw nProperty('n')) ; // true

// inherited property itself is still there
// but it's shadowed by instance's own property:
alert(obj.const ructor.prototyp e.n); // 5

// remove the own property shadowing
// the inherited one:
delete obj.n;

// inherited property is visible again:
alert(obj.n); // 5
alert(obj.hasOw nProperty('n')) ; // false
</script>

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

[Richard Cornford]

Re: defining classes-- different methods

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.hasOw nProperty('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.hasOw nProperty('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.const ructor.prototyp e.n); // 5
>
// remove the own property shadowing
// the inherited one:
delete obj.n;
>
// inherited property is visible again:
alert(obj.n); // 5
alert(obj.hasOw nProperty('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 "sophistica ted program" then?

Richard.

[Matt Kruse]

Re: defining classes-- different methods

VK wrote:

Well, if you are serious in what you are saying then your perception
of JavaScript and especially its inheritance is seriously damaged.

Your bickering is quite unproductive. And you are clearly wrong.

function C() { ; }
C.prototype.n = 5;
var obj = new C;
alert(obj.n); // 5

"Static" properties do not belong to an instance of a class, they belong to
the class itself.
In java, if a class has a static property and you access it as a property of
an instance, the compiler should throw a warning.

In the example above, how would you access the value of n without creating
an instance of C?

The answer is, you can't (other than looking at the prototype directly).
Accessing C.n will not work. If you have to create an instance of a class to
access a "static" property, then it's not a static property.

--
Matt Kruse

http://www.JavascriptToolbox.com

http://www.AjaxToolbox.com

[Bart Van der Donck]

Re: defining classes-- different methods

VK wrote:

The sigil itself in "tentativel y private member" name is for more easy
"visual" code navigation between the team members plus for automated
POD generation

I haven't the slightest idea what POD has to do with this.

http://search.cpan.org/~nwclark/perl-5.8.8/pod/perlpod.pod

(Hungarian notation would be way too "heavy" for JavaScript).

I don't see why that couldn't be a valid personal preference for a
coder. You seem to suggest that it isn't too "heavy" then in other
languages ?

"$" for sigil instead of say underscore is a personal preference (a
subconscious Perl influence maybe :-)

An underscore can never act as a sigil; underscores are part of the
variable's name.

--
Bart

[VK]

Re: defining classes-- different methods


Matt Kruse wrote:

"Static" properties do not belong to an instance of a class, they belong to
the class itself.

There is a single field/property/method instance "belonging" to class
but referenced in each class instance.

In java, if a class has a static property and you access it as a property of
an instance, the compiler should throw a warning.

>From what sky blue? Of course not (unless you have some paranoidal

compiler). But if I change static property over instance it will be
still "reflected" in all other instances as well.

In the example above, how would you access the value of n without creating
an instance of C?
The answer is, you can't (other than looking at the prototype directly).
Accessing C.n will not work. If you have to create an instance of a class to
access a "static" property, then it's not a static property.

How the h & f would anyone create "an instance of a class" without
having a class?
function C() {} in JavaScript
is not
public class C(){} in Java
and how the h & f would anyone talk about hardcoded inheritance in
JavaScript without prototype?

The turkey this year was really good and I don't want to spoil the rest
of my mood. Let's say that there is "js_static" methods where a single
method instance is shared by reference among all object instances (as
strictly opposed to real "static" method in say Java where a single
method instance shared by reference among all class instances).
Obviously only VK can take "js_static" for "static" when the difference
is so obvious.

I keep my freedom to call them static though, you may call it however
you want or just leave anonymous.

[VK]

Re: defining classes-- different methods

The sigil itself in "tentativel y private member" name is for more easy

"visual" code navigation between the team members plus for automated
POD generation

>
I haven't the slightest idea what POD has to do with this.
http://search.cpan.org/~nwclark/perl...od/perlpod.pod

Sorry, just slangish from my side. I meant (Perl in mind) automatically
generated help source out of information "encoded" in the program
source itself.

(Hungarian notation would be way too "heavy" for JavaScript).

>
I don't see why that couldn't be a valid personal preference for a
coder. You seem to suggest that it isn't too "heavy" then in other
languages ?

It is not in strictly typed languages with pointers and stuff. In
JavaScript a good half of the system would left unused. At the same
time absolutely nothing prevents of using the Hungarian notation in
JavaScript: anyone is welcome. That was nothing but my (our) particular
choice and I just provided the main reason of it.

"$" for sigil instead of say underscore is a personal preference (a
subconscious Perl influence maybe :-)

>
An underscore can never act as a sigil; underscores are part of the
variable's name.

Obviously we are talking "sigils" in the abstract way as some repeating
part of the identifier at the beginning: because JavaScript doesn't
have type modifiers ("sigils") as such. Whatever sign (or combination
of signs) it will it is always a part of the name (just like in
Hungarian notation). In this aspect "$" is no different from "_" or say
"prv".

[John G Harris]

Re: defining classes-- different methods

In article <1164713101.550 175.259560@n67g 2000cwd.googleg roups.com>, VK
<schools_ring@y ahoo.comwrites

<snip>

>the second one leads to the non-sense like
>"Array is Object, just with that funny length property added"

No-one is saying that.

>(Array is
>an object by it is not the Object: but it inherits from and extends

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^

>base Object constructor).

^^^^^^^^^^^^^^^ ^^^^^^^^
<snip>

That is not true.


John
--
John Harris

[Bart Van der Donck]

Re: defining classes-- different methods

VK wrote:

Obviously we are talking "sigils" in the abstract way as some repeating
part of the identifier at the beginning: because JavaScript doesn't
have type modifiers ("sigils") as such.

A sigil is not a modifier but a character that indicates the type of
the variable. It doesn't modify anything.

Whatever sign (or combination of signs) it will it is always a part of the
name (just like in Hungarian notation).

Sigils are certainly no part of the name. Say array @cars contains
('Audi', 'Opel', 'Toyota'), then $cars[0] could be 'Audi' and $#cars
the number of elements in the array (two).

The sigils here are @, $ and $# (the last one is actually a twigil).
But the variable's name is 'cars'; sigils are only *added* to a
variable. If you would say '@array_cars', then 'array_' is the
Hungarian part and '@' the sigil.

In this aspect "$" is no different from "_" or say "prv".

Yes, the discussion is irrelevant because no such things as sigils
exist in javascript. What you did is actually use $ as a Hungarian
notation, not as a sigil :-)

--
Bart