Terms for method types?

[VK]

<OT>I am finishing TransModal 0.1 so planning to move it from alpha to
beta stage.<OT>
Besides that I am planning to write an introductory to inheritance
schema currently used in Javascript programming. It will not be a
manual of a "proper" way to use OOP inheritance but a compilation so a
description of _all_ OOP paradigms that had been used or are being
used in Javascript commercial solutions: starting from the prototype
inheritance of course and ending up by mutable constructors over
closure-based inheritance (whatever I would be personally thinking of
this twist of the mind).

I am experiencing some terminology problems while thinking how to
describe different types of instance methods. The problem lies in the
ambiguous nature of the term "static" in different programming
languages. For example, think of i) "static" in VB where it is a type
of method preserving its state between calls and ii) "static" in Java
where it is a method shared between all class instances - this is
leaving aside "static" usage in C++ and especially in C.

This way I am thinking of unambiguous terms to denote in application
to Javascript the following types of methods:

1) The proposed term: "shared stateless". Functional similarity to
"static" in Java.
The most common type we are getting in say:
MyObject.prototype.method = function() {...}
or
function MyObject() {
this.method = MyObject.method;
}
MyObject.method = function() {...}

2) The proposed term: "own stateless"
Being created as a separate entity for each object instance
function MyObject() {
this.method = new Function(args, body);
}

3) The term I can think of: "own state preserving". Functional
similarity to "static" in VB.
Not convenient at all as a term but I would really like to avoid using
"static" word for above spelled reasons.
function outer() {
var myVar;
this.method = function() {...}
}

What would be the best terms to use? Are any types missing?

 

[Thomas 'PointedEars' Lahn]

Besides that I am planning to write an introductory to inheritance
schema currently used in Javascript programming. It will not be a
manual of a "proper" way to use OOP inheritance but a compilation so a
description of _all_ OOP paradigms that had been used or are being
used in Javascript commercial solutions: starting from the prototype
inheritance of course and ending up by mutable constructors over
closure-based inheritance (whatever I would be personally thinking of
this twist of the mind).

"Angels and ministers of grace defend us!"

I am experiencing some terminology problems while thinking how to
describe different types of instance methods. The problem lies in the
ambiguous nature of the term "static" in different programming
languages. For example, think of i) "static" in VB where it is a type
of method preserving its state between calls and ii) "static" in Java
where it is a method shared between all class instances

A static method in Java is instead a class method that can only be accessed
through the identifier of the class from outside the class (when both should
be public), or also with only its own identifier from within methods of the
class. Static also means that the method must not access instance variables
but can access static class variables (although this is uncommon).

In fact, in Java all instances share all public non-static methods of their
class.

But maybe you use an uncommon definition of "(to) share".

- this is leaving aside "static" usage in C++ and especially in C.

You are creating a problem where none exists, by trying to apply
class-based thinking to a prototype-based programming language.

This way I am thinking of unambiguous terms to denote in application
to Javascript the following types of methods:

1) The proposed term: "shared stateless". Functional similarity to ^^^^^^^^^^^^^^^^^^^^^^^^
"static" in Java. ^^^^^^^^^^^^^^^^^
The most common type we are getting in say:
MyObject.prototype.method = function() {...}

^^^^^^^^^^^^^^^^^^^^^^^^^
Nonsense, see below.

You could say "`method' is the identifier/name of a prototype method of
MyObject" (or, more precisely, "... of the object referred to by
`MyObject'). Or you could say "`method' is (the identifier/name of a)
method of MyObject's prototype object."

or
function MyObject() {
this.method = MyObject.method;
}
MyObject.method = function() {...}

`method' will be the identifier of a method of an object.

In the first case, that object will be the Global Object when MyObject
is [[Call]]ed or, more likely, "an object created with the MyObject()
constructor" (or short, a "MyObject object" if you will) if MyObject()
is [[Construct]]ed with `new'.

In the second case, that object will be "the Function object that `MyObject'
refers to", or "the MyObject (Function) object" if you will. (Of course, for
the sake of brevity, the short form is deliberately ignoring that MyObject's
value is but a reference to an object and does not need to solely represent
that object in the source code.) *This* if anything would be functional
similar to a public static method in Java. As in an ECMAScript
implementation used in an HTML UA:

function Foo() {}

Foo.bar = function() {
return 42;
};

// unused variable
var foo = new Foo();

document.write(Foo.bar());

Then the constructor referred to by `Foo' would correlate to the class
`Foo', and the constructor's method referred to by `bar' would correlate
to the public static method `bar' of that class. As in Java:

Foo.java:

package comp.lang.javascript.foobar;

public class Foo
{
public static long bar()
{
return 42L;
}
}

Bar.java:

package comp.lang.javascript.foobar;

public class Bar
{
public static void main(String[] args)
{
// WARNING: the local variable `foo' is never read
Foo foo = new Foo();

System.out.print(Foo.bar());
}
}

2) The proposed term: "own stateless" ^^^^^^^^^^^^^
Being created as a separate entity for each object instance
function MyObject() {
this.method = new Function(args, body);
}

Nonsense.

var foo = new MyObject();
window.alert(foo.method);

3) The term I can think of: "own state preserving". ^^^^^^^^^^^^^^^^^^^^
Functional similarity to "static" in VB.
Not convenient at all as a term but I would really like to avoid using
"static" word for above spelled reasons.
function outer() {
var myVar;
this.method = function() {...}
}

Nonsense as well:

var foo = new MyObject();
foo.method = function() { return 42; };
window.alert(foo.method());

Neither with (2) nor (3) does the property not have a state
or could preserve its own state or that of its owner object.

What would be the best terms to use?

The *specified*, precise but concise, and least gibberish ones.
(Given your record here, would you be even capable of that?)

Are any types missing?

ISTM any other type would be but a variation of one of those presented,
made possible by the dynamic nature of the programming language.


PointedEars

 

[RobG]

<OT>I am finishing TransModal 0.1 so planning to move it from alpha to
beta stage.<OT>
Besides that I am planning to write an introductory to inheritance
schema currently used in Javascript programming. It will not be a
manual of a "proper" way to use OOP inheritance but a compilation so a
description of _all_ OOP paradigms that had been used or are being
used in Javascript commercial solutions: starting from the prototype
inheritance of course and ending up by mutable constructors over
closure-based inheritance (whatever I would be personally thinking of
this twist of the mind). [...]
This way I am thinking of unambiguous terms to denote in application
to Javascript the following types of methods:

1) The proposed term: "shared stateless". Functional similarity to
"static" in Java.
The most common type we are getting in say:
  MyObject.prototype.method = function() {...}

That represents classic prototype inheritance, why does it need
another name?

or
  function MyObject() {
   this.method = MyObject.method;
  }
  MyObject.method = function() {...}

That doesn't represent inheritance at all, it is completely different
to the previous pattern. Changing the function assigned to
MyObject.method will not change the "method" property of already
constructed instances of MyObject.

The use of "MyObject.method" has no special significance at all,
though it may be convenient from a maintenance viewpoint to indicate
those methods that will be public properties of instances of
MyObject. But they aren't inherited, just assigned by the
constructor.

2) The proposed term: "own stateless"
Being created as a separate entity for each object instance
   function MyObject() {
    this.method = new Function(args, body);
   }

I don't see that this has any practical difference to the second
method of 1. above except that it is probably less efficient since
each instance of MyObject will have its own instance of the method.
Perhaps it is similar to currying:

3) The term I can think of: "own state preserving". Functional
similarity to "static" in VB.
Not convenient at all as a term but I would really like to avoid using
"static" word for above spelled reasons.
  function outer() {
   var myVar;
   this.method = function() {...}
  }

Does "closure" ring a bell?

 

[VK]

Thomas and Rob,
first of all thanks for your responses.
Secondly, you seem misinterpreted my question, which is most probably
caused by the fact that I illustrated each method type by a code
sample: so you commented to these particular samples and their nature.
Other words with a question like "The fruits, say this apple: what can
we say about fruits?" the answers came to "About this apple we can say
that..."

To facilitate the needed level of abstraction I am interested in right
now let's abandon for a second any particular code samples of a
particular language so being using an abstract OOP model.

In such model we have a template of some kind to produce object
instances with identical set of initial properties. An attempt to call
such template "a class" in the sense "a class of things", "a set of
things of the same kind" in application to Javascript usually gets a
furious offense at clj because of possible misinterpretation in terms
of class-based inheritance. It worth mention that such rigorous
terminological approach is not sustained by the current ECMA-262 3rd
ed. documentation where "class" as "kind of this object" is freely
used, see for instance "8.6.2 Internal Properties and Methods".
From the other side an equal offense can be put from the class-based
programming point of view on using "a prototype" in the sense "a model
on which something is based or formed". With the same reason C++'er or
Javer may argue that "C++ doesn't have prototypes, it is a class-based
language". Other words the parasite meaning of "a prototype" from one
end is as strong as "a class" from the other one.
At the same time it is plain ridiculous to affirm that there is not a
common underlaying idea behind both paradigms: they are both OOP-
based. If "a prototype" and "a class" are not suggested as terms in
common descriptions as bringing too much of parasite context, we need
a term free of such context yet commonly understood so not requiring a
definition of its own. I see such term either as "a template" or "a
model" being open for alternative proposals. So far and further in the
text I'll be using "a template".

By having a build-in or custom made template, we can create new
instances based on such template. Each new instance will have the same
initial set of members. These members can be either properties or
methods. The properties can be read-only, read/write, write-only. The
methods can be also called, so being subroutines attached to an
object.
btw it is another terminological problem to solve at least in
application to Javascript. The initial OOP distinction was "properties
and methods forming the set of object members". The term "a member"
seems faded away by now. At the same time the higher level Javascript
programming (Mozilla XBL and Microsoft HTC) as well as many other OOP
languages do have a strict distinction between primitive "field"
property and getter/setter based "property" property. That prevents
from saying "fields and methods forming the set of object properties"
due to possible misunderstanding. As the result it is common to see
the term "a property" being used both as an opposition to "a method"
and in the generic sense "a member". The resulting oftenly seen or
implied descriptions of the kind "properties and methods forming a set
of object properties" are sub-optimal to say the least IMO.
Any thoughts or proposals?

To continue from where we stopped:

By having a build-in or custom made template, we can create new
instances based on such template. Each new instance will have the same
initial set of members. Some of these members may be instance methods
we can call.
By their internal representation and by their external behavior there
are three generic types of methods:

1) A method being internally represented by a single entity. The
object instances do share this entity. Each instance may call this
entity and for the period of call an appropriate context will be
created within the method with say "this" pointing to the calling
instance so making possible to operate in the context of call with all
other instance members. On call end the context gets released and the
method is again formally "of no one's" until the next call. Basically
it is the only type of method the original OOP model have planned,
because instance individualization was assumed to be done over fields
and properties change, with shared methods to manipulate these fields
and properties per instance yet keep the memory usage to its minimum.
This type of method I am calling "shared stateless" being open for any
other proposals on the conditions of i) not using "static" word
because of semantical slash between different programming languages
and ii) not implying any particular programming language and iii)
being meaningful from its own.

2) Nevertheless Her Majesty Encapsulation states that whatever can be
potentially hidden - it must hidden. This caused the appearance of
methods appertaining to their respective owners. In this case in
application to methods the template is working as a factory, so for
each new object instance a new clone of the method is being made. From
one side it is a "memory killer" because for N instances N identical
methods are created instead of just one shared as in case 1). From the
other side it allows to shift the further individualization of
instances from its fields and properties into encapsulated context of
the method clone.
This type of method, being cloned for each instance and able to
preserve its context between calls, I call "own state preserving" and
I'd really like to have a nicer one on the conditions of i) not
implying any particular programming language and ii) being meaningful
from its own. This is why Rob's suggestion of "closure", however
evident it would be, alas is not suitable.

3) The third and the last type of method is more or less Javascript-
specific. It appeared as a quick'n'dirty way to break parasite
closures introduced with nested functions paradigm. I will be using
this type for criticism only yet it still has to be called somehow
Basically it is the same "own state preserving" type as 2) but with
the context preserving removed. Other words for N object instances N
method being cloned with the instance-specific context being re-
initialized for each call.
I call it "own stateless" and I am open for other proposals.

 

[Joost Diepenmaat]

This way I am thinking of unambiguous terms to denote in application
to Javascript the following types of methods:

1) The proposed term: "shared stateless". Functional similarity to
"static" in Java.
The most common type we are getting in say:
MyObject.prototype.method = function() {...}

As someone else already remarked; this is just basic prototype
inheritance. The method will indeed be shared by objects that share
that prototype, but wether or not that method maintains state(s)
depends on its definition and the way it will be called (remember
*ALL* functions can access /some/ "this" object, no matter how you
call them).

or
function MyObject() {
this.method = MyObject.method;
}
MyObject.method = function() {...}

This copies references around instead of sharing them, so it's not the
same thing at all and I would consider it a variant of the "own XXX"
examples below. Same objection to the term "stateless" as above.

2) The proposed term: "own stateless"
Being created as a separate entity for each object instance
function MyObject() {
this.method = new Function(args, body);
}

Ok; create a new function object. Is there any reason you're not a
function() {} expression instead of the "eval pretending to be
something else" new Function construct?

Again, this function may or may not have state; there's no way to tell.

3) The term I can think of: "own state preserving". Functional
similarity to "static" in VB.
Not convenient at all as a term but I would really like to avoid using
"static" word for above spelled reasons.
function outer() {
var myVar;
this.method = function() {...}
}

What would be the best terms to use? Are any types missing?

This may be a closure (but again, I can't tell because you omit the
function body, all the other examples might also be
closures). Closures are orthogonal to inheritance so I just look at
the assignment and would consider this the same thing as the above 2
examples.

I think you're overthinking. There is only 1 thing to consider here;
where in the prototype chain the method/property is placed. This stuff
really only gets interesting when you've got more than one level of
inheritance and "instances" at different levels.

 

[VK]

As someone else already remarked; this is just basic prototype
inheritance.

And I am saying "thanks to everyone" for the enlightenment Please
see my second post in this thread for clarifications. I don't care -
on this stage - about the exact inheritance mechanics, would it be:

function MyObject() {
// ...
}
MyObject.prototype.myMethod = function() {
// ...
}
var myInstance = new MyObject;

or

package MyClass;
sub new { bless( {}, shift ) }
sub myMethod {
# ...
}
package main;
$myInstance = MyClass->new();

or

public class MyClass {
public static void myMethod() {
// ...
}
}
myInstance = new MyClass();

or any other from the legion of implementations of the core idea "N
instances - one shared method". They all have different syntax,
internal representation and behavioral details, but it is still the
same idea. Just like the presence of "I go", "Je vais", "Ich gehe"
etc. doesn't deny the presence of the idea of the doer and the action.

The method will indeed be shared by objects that share
that prototype, but wether or not that method maintains state(s)
depends on its definition

That is more interesting. Can you provide a sample from a programming
language with a single shared (Java-static) method preserving call
state(s) for individual instances?

(remember
*ALL* functions can access /some/ "this" object, no matter how you
call them).

Of course for Javascript - because here functions are first-class
objects. Yet we are talking about OOP, and
myInstance = new MyClass();
var foo = myInstance.myMethod;
foo();
and similar has no relation to OOP: it is just a pointless hack
syntactically allowed due to the intentionally flexible nature of
Javascript.
What we are interested in is OOP domain and the concept "N instances -
one shared method".
"shared stateless" to be exact but you have mentioned the possibility
of "shared state preserving" and I would like to see a possible
implementation of it.

This copies references around instead of sharing them, so it's not the
same thing at all and I would consider it a variant of the "own XXX"
examples below.

I say that you are making two errors here: one semantical and other
technical. The semantical one is that two different things do not
necessary mean two different concepts, just like "I go" and "Je vais"
do not. You don't say that "but they are doing all different things!
This one _goes_, other one _va_"
The technical error is that of course just like with the prototype
chain we are having here one single method instance shared among all
object instances. You may check it by say:
function MyObject() {
this.shared = MyObject.shared;
this.own1 = new Function;
/* closure prone, but to be complete: */
this.own2 = function(){};
}
MyObject.shared = function(){};

var a = new MyObject;
var b = new MyObject;

window.alert(a.shared === b.shared); // true
window.alert(a.own1 === b.own1); // false
window.alert(a.own2 === b.own2); // false

Ok; create a new function object. Is there any reason you're not a
function() {} expression instead of the "eval pretending to be
something else" new Function construct?

Yes. Read the definition: "own _stateless_". In the particular
application to Javascript it means that for N object instances N
method clones are created: but each clone does not create a closure
over it so it doesn't keep in-between-calls state. In my second post
in this thread I mentioned that I was planning to use this type of
method for criticism only, though in some particular cases such type
of method might be useful.
To fully answer to your question I am going to illustrate the regular
path of how an average not fully influenced in Javascript programmer
arrives to this type of method.
So taking an average John Doe who just learned that
function a() {
}
function b() {
}
is absolutely lame and that everyone from San Francisco to Tokyo over
Europe is already being cool by doing
function a() {
function b() {
}
}
or
function a() {
this.m = function() {};
}
and other similar cool things which is not a shame to show to your
girl. Does John Doe want to be a loser and see his girl leaving him
for a guy doing nested function? Surely not.

function MyObject(data) {
// do with data
// set other members
this.method = function(){};
}

var myInstance = new MyObject("a lot of data");

Now the question is what happened with "a lot of data" after the last
statement? Contrary to the common believe it did not get garbage
collected even if "a lot of data" was a literal or a function return
value or even a variable explicitly set to null after being used.
By using the nested function expression we have created a closure for
the entire context of MyObject as it was at the end of each particular
call - and we have created as many of such closures as the amount of
object instances. Each MyObject instance will have its own copy of "a
lot of data" moreover retained by two references: by named argument
"data" and by automatically created arguments[0]. Here is the point
where "my memory is leaking on IE!" complains are coming. It is funny
that from my observations the complains are always targeted to IE even
if the testing was done under Firefox or another browser: as if IE had
some evil power to suck the memory out remotely from all other
rivals.
In this aspect "own stateless" method we started with allows to keep
method assignment within the constructor, to clone it for each
instance yet allows to avoid closures unless they are expected and
needed by the programming logic. One of simplest ways is to use
Function constructor instead of assigning function expression though
there are other ways.
function MyObject(data) {
// do with data
// set other members
this.method = new Function(args, code);
}

var myInstance = new MyObject("a lot of data");

Again, this function may or may not have state; there's no way to tell.

Right the opposite as I explained, it is very easy to tell:
this.method = new Function(args, code);
will not have state in any case unless a secondary function
augmentation which is kind of out of subject right now, and
this.method = function(){};
will have state no matter what, the only option is to explicitly set
all in-closure variables to null. The "state" (the closure) will still
remain but it will contain the minimum of data.

This may be a closure (but again, I can't tell because you omit the
function body, all the other examples might also be
closures). Closures are orthogonal to inheritance so I just look at
the assignment and would consider this the same thing as the above 2
examples.

You are wrong again but I explained the difference in details in the
previous type's description so I refer to it.

I think you're overthinking. There is only 1 thing to consider here;
where in the prototype chain the method/property is placed. This stuff
really only gets interesting when you've got more than one level of
inheritance and "instances" at different levels.

I do not agree here. Before going to prototypes, classes, their
differences and possible usage some more generic entities have to be
set and understood. Just like before learning a language it is most
useful to learn the alphabet and the distinction between different
parts of speech. IMO.

 

[Lasse Reichstein Nielsen]

First of all, have you read:
http://javascript.crockford.com/private.html
http://javascript.crockford.com/prototypal.html
http://javascript.crockford.com/inheritance.html

1) The proposed term: "shared stateless". Functional similarity to
"static" in Java.

This needs no name. It's the default for functions in Javascript.

In Java, all methods have to belong to a class. Static methods are
simply methods that does not belong to an object, but does live
in the scope of a class definition.

Javascript has no classes, and few scopes, so a "shared stateless"
function would be
var foo = {};
foo.sharedStateless = function() { ... };
It's accessible anywhere the foo object is, and foo is just used
as a namespace.

The most common type we are getting in say:
MyObject.prototype.method = function() {...}

This is prototype inheritance. Objects created using the MyObject
constructor will inherit the "method" function. There is only
"method" function, but when called as a method, i.e.,
myObject.method()
it can operate on the object it is called on. The method decides
whether to do so by using the "this" operator.

or
function MyObject() {
this.method = MyObject.method;
}

This is wastefull, but effecively equivalent to the above.
Instead of inheriting the method, each object created using
the MyObject constructor will have the method assigned.
It's still the same function in all the cases, and if called
as a method, it can operate on the object it was called on.

MyObject.method = function() {...}

That's equivalent to my namespace above. It doesn't matter
that MyObject is a function object, it's merely used as a
namespace.

2) The proposed term: "own stateless"
Being created as a separate entity for each object instance
function MyObject() {
this.method = new Function(args, body);
}

If it's stateless, then it doesn't matter whether it's created
again or you use the same function for all objects. No need
for a separate name, as there is no use for this construction.

3) The term I can think of: "own state preserving". Functional
similarity to "static" in VB.
Not convenient at all as a term but I would really like to avoid using
"static" word for above spelled reasons.
function outer() {
var myVar;
this.method = function() {...}
}

I wouldn't mind using "static" for the variable, but I have a history
with C as well as Java. This is what have previously been called a
private variable. I.e., focusing on the scope of the variable, not
the functions.

What would be the best terms to use? Are any types missing?

I think there are too many types, if anything.

/L

 

[Joost Diepenmaat]

To start off: I'm going to quote large sections here, because I think
this post won't make sense otherwise.

Anyway,

And I am saying "thanks to everyone" for the enlightenment Please
see my second post in this thread for clarifications. I don't care -
on this stage - about the exact inheritance mechanics, would it be:

function MyObject() {
// ...
}
MyObject.prototype.myMethod = function() {
// ...
}
var myInstance = new MyObject;

or

package MyClass;
sub new { bless( {}, shift ) }
sub myMethod {
# ...
}
package main;
$myInstance = MyClass->new();

or

public class MyClass {
public static void myMethod() {
// ...
}
}
myInstance = new MyClass();

or any other from the legion of implementations of the core idea "N
instances - one shared method". They all have different syntax,
internal representation and behavioral details, but it is still the
same idea. Just like the presence of "I go", "Je vais", "Ich gehe"
etc. doesn't deny the presence of the idea of the doer and the action.

I see what you're saying, but I don't agree it's the right way to go
about explaining inheritance in JS. I'll get to that general point at
the end of this post.

That is more interesting. Can you provide a sample from a programming
language with a single shared (Java-static) method preserving call
state(s) for individual instances?

First off, I was talking about javascript, not java. It's very easy to
do this in JS, and AFIAK not at all possible in java (I don't know
enough about java introspection to rule it out completely). How about
this (perl) example:

my %params;
sub semi_static_method {
my ($class,$param) = @_;
$params{$class} = $param;
}

Note that the $class variable has a deliberately misleading name.

Of course for Javascript - because here functions are first-class
objects. Yet we are talking about OOP, and
myInstance = new MyClass();
var foo = myInstance.myMethod;
foo();
and similar has no relation to OOP: it is just a pointless hack
syntactically allowed due to the intentionally flexible nature of
Javascript.

It's not pointless exactly. The interpretation of "this" in JS
functions/methods and the how/if inheritance is resolved is completely
defined by how the function/method is called. IMO trying to push a
class/instance view of the OO world is misleading at best.

What we are interested in is OOP domain and the concept "N instances -
one shared method".
"shared stateless" to be exact but you have mentioned the possibility
of "shared state preserving" and I would like to see a possible
implementation of it.

See above. Also, you didn't make it at all clear that you meant
per-object state and not per-class state; per-class state is easy in
most langauges. And then there are closures.

I say that you are making two errors here: one semantical and other
technical. The semantical one is that two different things do not
necessary mean two different concepts, just like "I go" and "Je vais"
do not. You don't say that "but they are doing all different things!
This one _goes_, other one _va_"

I just don't see the point of doing this at all, unless some objects
constructed using this function do have different methods. The only
other explanation is that you're micro-optimizing for method calls.

The technical error is that of course just like with the prototype
chain we are having here one single method instance shared among all
object instances. You may check it by say:
function MyObject() {
this.shared = MyObject.shared;
this.own1 = new Function;
/* closure prone, but to be complete: */
this.own2 = function(){};
}
MyObject.shared = function(){};

var a = new MyObject;
var b = new MyObject;

window.alert(a.shared === b.shared); // true
window.alert(a.own1 === b.own1); // false
window.alert(a.own2 === b.own2); // false

Yeah I know. So why not put the method in the prototype. At the very
least it will reduce the amount of code, and will make instantiation
objects cheaper.

Yes. Read the definition: "own _stateless_". In the particular
application to Javascript it means that for N object instances N
method clones are created: but each clone does not create a closure
over it so it doesn't keep in-between-calls state.

Unless the body uses "this", of course.

In my second post
in this thread I mentioned that I was planning to use this type of
method for criticism only, though in some particular cases such type
of method might be useful.
To fully answer to your question I am going to illustrate the regular
path of how an average not fully influenced in Javascript programmer
arrives to this type of method.
So taking an average John Doe who just learned that
function a() {
}
function b() {
}
is absolutely lame and that everyone from San Francisco to Tokyo over
Europe is already being cool by doing
function a() {
function b() {
}
}
or
function a() {
this.m = function() {};
}
and other similar cool things which is not a shame to show to your
girl. Does John Doe want to be a loser and see his girl leaving him
for a guy doing nested function? Surely not.

I'm sure I don't know what you mean.

function MyObject(data) {
// do with data
// set other members
this.method = function(){};
}

var myInstance = new MyObject("a lot of data");

Now the question is what happened with "a lot of data" after the last
statement? Contrary to the common believe it did not get garbage
collected even if "a lot of data" was a literal or a function return
value or even a variable explicitly set to null after being used.

There's not much point in collecting literals.

By using the nested function expression we have created a closure for
the entire context of MyObject as it was at the end of each particular
call - and we have created as many of such closures as the amount of
object instances. Each MyObject instance will have its own copy of "a
lot of data" moreover retained by two references: by named argument
"data" and by automatically created arguments[0].

I'd have to re-read the treadment of literal strings in the specs
again to be sure about this case, but I'm quite sure that passing an
object literal doesn't necessarily mean it gets copied. In fact, a
reasonably smart compiler/interpreter should see that no variables are
captured by your function(){} "closure" just by static
analysis. That's one of good points of lexical scoping.

Here is the point
where "my memory is leaking on IE!" complains are coming. It is funny
that from my observations the complains are always targeted to IE even
if the testing was done under Firefox or another browser: as if IE had
some evil power to suck the memory out remotely from all other
rivals.

Browsers suck. IE is just the most feckless of all the current
browsers. FTR, today's firefox 3 sucks ass too.

In this aspect "own stateless" method we started with allows to keep
method assignment within the constructor, to clone it for each
instance yet allows to avoid closures unless they are expected and
needed by the programming logic. One of simplest ways is to use
Function constructor instead of assigning function expression though
there are other ways.
function MyObject(data) {
// do with data
// set other members
this.method = new Function(args, code);
}

new Function(...) is one of the most expensive calls in all of JS. And
as I hinted above, it's completely useless unless you really *need*
eval() like construct. This does not all look like such a situation.

var myInstance = new MyObject("a lot of data");


Right the opposite as I explained, it is very easy to tell:
this.method = new Function(args, code);
will not have state in any case unless a secondary function
augmentation which is kind of out of subject right now, and
this.method = function(){};

what about

code = "this.bla = arguments[0]";

*snipped stuff I just don't get or disagree with*

I do not agree here. Before going to prototypes, classes, their
differences and possible usage some more generic entities have to be
set and understood. Just like before learning a language it is most
useful to learn the alphabet and the distinction between different
parts of speech. IMO.

But prototypes are much *simpler* than classes and instances. AFAICT
you're pushing your java-like view of OO onto JS and it isn't a good
match. Most of OO is about instance methods, and for instance methods,
JS's prototype inheritance is simpler to explain and understand even
though it's more flexible. The issues mostly come in when with
inherited class methods, and

1) you don't really need them that often

2) they're actually relatively simple once you get a proper view of
prototypical inheritcance.

Also, classes are just performance "hacks" based on prototype
inheritance. See for a pretty good example, Paul Graham's "ANSI Common
Lisp" chapter 17, which builds a complete class/instance OO system out
of functions and structs via prototype inheritance. That's not to say
that explicit classes don't have documentation value, by the way.

 

[RobG]

[...]
It's not pointless exactly. The interpretation of "this" in JS
functions/methods and the how/if inheritance is resolved is completely
defined by how the function/method is called.[/QUOTE]

That seems a bit confused to me, the value of a function's this
keyword is set by the call, I don't think that relates to inheritance
at all.

The iheritance chain is defined when an object is created and follows
internal [[prototype]] properties (except for the use of with
statements, but that is a different story). Once the chain is created
for a particular object by a call to its constructor, you can't change
it, you can only modify the public properties of the objects on the
chain.

[...]

I say that you are making two errors here: one semantical and other
technical. [...]
The technical error is that of course just like with the prototype
chain we are having here one single method instance shared among all
object instances.

It is quite different to prototype inheritance. If you change a
property of a prototpye object, that change is iherited by all objects
that have that prototype in common. However, if you assign a
different function to MyObject.method, it is only inherited by new
instances of MyObject.


And if you do:

MyObject.shared = function(){};
var c = new MyObject();
window.alert(a.shared === c.shared); // false

[...]

 

[Joost Diepenmaat]

That seems a bit confused to me, the value of a function's this
keyword is set by the call, I don't think that relates to inheritance
at all.

Inheritance and resolving of "this" are two independent issues, but
they're both affected by how the function is called (or technically,
the inheritance is resolved when the function is accessed, and the
"this" issue is resolved when it's callled).

The iheritance chain is defined when an object is created and follows
internal [[prototype]] properties (except for the use of with
statements, but that is a different story).

I don't think with() statements have any effect on inheritance. Could
you explain in a little more detail?

 

[RobG]

The iheritance chain is defined when an object is created and follows
internal [[prototype]] properties (except for the use of with
statements, but that is a different story).

I don't think with() statements have any effect on inheritance. Could
you explain in a little more detail?

They don't, I got confused between property and identifier
resolution. :-(

 

[VK]

1) The proposed term: "shared stateless". Functional similarity to

I see what you're saying, but I don't agree it's the right way to go
about explaining inheritance in JS.

We are not explaining the inheritance in JS so far: we are explaining
the inheritance, template (class or prototype), instance,
encapsulation, property and method as concepts and how do they go by
"one per instance" vs. "one for all" distinction. If none of it can be
explained without using some specific programming language and exact
entities of this specific language then we have to sorrily admit then
that OO (OOP) doesn't exist as a concept as well: there is then only a
loose set of unrelated language-specific techniques. I do think that
it is not true.
That would be better(?) maybe if for anything language-specific
language makers would be using newly made words like whatchamacallit,
whatchamacallthis, whatchamacallthat etc. This way for explanation one
could freely use the regular English words like class, prototype,
final etc. in their common meaning. But expectedly - and btw thanks to
that - the makers are normally using regular English words in a new
applied meaning for language keywords.
This is why I was calling in previous post to avoid a hysteria each
time a word may have a semantical slash with this or that programming
language. Just let's take a deep breath and try to find a unused
synonym if such semantical slash is _indeed_ so serious and leading to
misunderstanding.
In this aspect the usage of "a template" instead of "a class" or "a
prototype" seems justified(?) while "an instance" just fine as it is.
"shared" instead of "static" is definitely justified in view of C vs.
VB vs. C++/Java usages.
The other terms and necessary - if necessary - alternatives can be
discussed as it goes.

First off, I was talking about javascript, not java. It's very easy to
do this in JS, and AFIAK not at all possible in java (I don't know
enough about java introspection to rule it out completely).

The introspection as like: http://en.wikipedia.org/wiki/Introspection_(computer_science)
?

How about
this (perl) example:

my %params;
sub semi_static_method {
my ($class,$param) = @_;
$params{$class} = $param;

}

This is a particular case of the method augmentation. As I said
before
(http://groups.google.com/group/comp.lang.javascript/msg/
6e2d3d616109b87c) :
" this.method = new Function(args, code);
will not have state in any case unless a secondary function
augmentation which is kind of out of subject right now"
The above applies as well to the secondary augmentation of shared
stateless methods: it is possible, sometimes used, but it has very
weak relation with OOP matters. If we straighten up all this stuff
then it comes to something simple like:

var extraStorage = {};

function MyObject(key) {
this.key = key;
extraStorage[key] = this;
}
MyObject.prototype = function() {
// do with extraStorage[this.key];
}

Other words these are the same owned (per instance) methods just
"outsourced" for whatever reason over shared method used as some kind
of interface.

It's not pointless exactly. The interpretation of "this" in JS
functions/methods and the how/if inheritance is resolved is completely
defined by how the function/method is called. IMO trying to push a
class/instance view of the OO world is misleading at best.

Not class/instance because of potential semantical collision: but
template/instance view. Here there is nothing to push because it does
definitely exists in Javascript and extensively used in any modern
program. The "push" can be used only to the OOP itself: because
technically and practically it is possible to write plain linear
programs in Javascript without any prototypes and/or custom methods,
only with subroutines calling other subroutines etc. OOP in Javascript
is not the only way to program: it is only the most suggested - or
"pushed" if you want.

See above. Also, you didn't make it at all clear that you meant
per-object state and not per-class state; per-class state is easy in
most langauges. And then there are closures.

I am not sure I was using "per-object state" and "per-class state"
terms pair. When using "state" or "stateless" I am referring to the
state of a method in application to an object instance: say each
instance has its own Counter variable in its method and its value may
be different for each instance at once. Therefore "per-class state" is
not bearing too much sense to me. Unless you are talking about derived
classes over mutable constructors, like:
function outer(val) {
return function inner() {
this.property = val;
}
}

var f1 = new outer("foo");
var f2 = new f1;
// f2.property == "foo" over closure
// in the mutable constructor

My personal attitude to the closure-based inheritance is strictly
negative, but we will definitely talk about it - I mentioned it in my
original post. I just would like do not jump on everything at once:
before learning to mix things together it is most useful to study the
ingredients first. This is actually why I started this thread because
I am not satisfied at all by existing Javascript inheritance articles.
The amount of strange code samples and questions like "what a hey
prototype is?!" suggest that many Javascript beginners do not get them
as well. IMHO 99% of existing materials can be divided in two groups.
One is "canonical", where slightly altered quotations from ECMAScript
docs are illustrated by one-two samples. Normally readers are leaving
such articles with the knowledge that "Javascript doesn't have
classes, it is prototype based" - thus one obscure sentence more than
they knew before start reading such article, so even lesser than
before
The other type is "hackerly". This type style appeared at the
beginning of this century and still bearing IMHO the inferiority
complex of times when Javascript was considered as a lightweight toy
language for form pre-validation and so. As the result the authors
first trying to show how complex, tricky and misunderstood Javascript
can be. So instead of clear step-by-step explanations of the most used
everyday techniques they are dropping their readers into some complex
diagrams, samples where prototype is not prototype, constructor is not
constructor, instance is not instanceof and anything else from
undocumented and badly documented engine behavior.
I would really like to stay in the middle. So are closures, mutable
constructors, constructor != function constructor etc. possible? Yes,
of course. But let's hold the breath till the appropriate moment for
that ;-)
Let's us finish with the basic terms and pure prototype inheritance
first.

I just don't see the point of doing this at all, unless some objects
constructed using this function do have different methods. The only
other explanation is that you're micro-optimizing for method calls.

"micro-optimizing" for sure, up to "macro-optimizing" in many
circumstances because in Javascript internal object references are not
reusable. But I guess I am breaking my own intention to go step-by-
step. Overall it is just the ol'good OOP method as it was at beginning
of JavaScript and during the most of the Browser Wars. It is only
adjusted in respect of the modern taboo-demand to keep the global
namespace as clear as humanly possible. In some 1997/98 it simply
would be like:

function VK_MyObject() {
this.method = VK_method;
}

function VK_method() {
// ...
}

Yeah I know. So why not put the method in the prototype. At the very
least it will reduce the amount of code, and will make instantiation
objects cheaper.

Sometimes, yes. Pure canonical prototype inheritance has its caveats
as well though. We will talk about it after we decide what terms to
use in explanations and after actually explaining the pure canonical
prototype inheritance.

Unless the body uses "this", of course.

The body of what? Do you mean the outer function?

I'm sure I don't know what you mean.

good

There's not much point in collecting literals.

I guess I need to introduce some symbol to denote "anything
technically possible to use as a function argument". Please read "a
lot of data" as such symbol

By using the nested function expression we have created a closure for
the entire context of MyObject as it was at the end of each particular
call - and we have created as many of such closures as the amount of
object instances. Each MyObject instance will have its own copy of "a
lot of data" moreover retained by two references: by named argument
"data" and by automatically created arguments[0].

I'd have to re-read the treadment of literal strings in the specs
again to be sure about this case, but I'm quite sure that passing an
object literal doesn't necessarily mean it gets copied.

In this case your understanding of the nature of the closure is not
full so far. Again, in my sample "a lot of data" doesn't necessary
mean a string literal "a lot of data". _Anything_ being stoke in a
closure never released unless manually cleared out. This is why once a
while ago I said that using closures is like sending Devil to do the
job. It may do exactly what you want but the price may be high and the
most unexpected one.
A "contract" to think over at your spare time:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Proto : 1</title>
<script type="text/javascript">

function MyObject(data) {
this.propertyOne = function(){
eval("window.alert(data)");
};
}

var obj = [1,2,3];

var myInstance = new MyObject(obj);

var obj = null;

window.setTimeout("myInstance.propertyOne()",1000);
</script>
</head>
<body>
<p>No content</p>
</body>

In fact, a
reasonably smart compiler/interpreter should see that no variables are
captured by your function(){} "closure" just by static
analysis. That's one of good points of lexical scoping.

Again, your understanding of _documented_ and expected closure
mechanics in Javascript needs more improvement.

Browsers suck. IE is just the most feckless of all the current
browsers. FTR, today's firefox 3 sucks ass too.

The world sucks for a starter But we have to deal with it as it
is.

 

[Joost Diepenmaat]

We are not explaining the inheritance in JS so far: we are explaining
the inheritance, template (class or prototype), instance,
encapsulation, property and method as concepts and how do they go by
"one per instance" vs. "one for all" distinction. If none of it can be
explained without using some specific programming language and exact
entities of this specific language then we have to sorrily admit then
that OO (OOP) doesn't exist as a concept as well: there is then only a
loose set of unrelated language-specific techniques. I do think that
it is not true.

The only really interesting way to share methods in JS is by
inheritance. IOW all you really need to explain here is methods as
properties of an object vs methods as properties of a prototype of an
object. You only need 2 examples for that and your four examples and
slightly confusing terminology are not making things clearer.

You need to explain only a couple of things at this point:

1. functions are objects in their own right which means they can be
copied.

2. objects are just bags of properties with associated values.

3. methods are properties who's values are functions.

4. some general hint that an object's prototype is consulted for
"missing" properties (which you may or may not call inheritance).

And leave out any discussion state etc till after you've explained
this. You're making things appear much more confusing than they
actually are.

That would be better(?) maybe if for anything language-specific
language makers would be using newly made words like whatchamacallit,
whatchamacallthis, whatchamacallthat etc. This way for explanation one
could freely use the regular English words like class, prototype,
final etc. in their common meaning. But expectedly - and btw thanks to
that - the makers are normally using regular English words in a new
applied meaning for language keywords.
This is why I was calling in previous post to avoid a hysteria each
time a word may have a semantical slash with this or that programming
language. Just let's take a deep breath and try to find a unused
synonym if such semantical slash is _indeed_ so serious and leading to
misunderstanding.
In this aspect the usage of "a template" instead of "a class" or "a
prototype" seems justified(?) while "an instance" just fine as it is.
"shared" instead of "static" is definitely justified in view of C vs.
VB vs. C++/Java usages.

My take on these terms is that in JS, the basic mechanism is
inheritance via prototypes (*not* templates). People *need* to get
that into their heads first. If you want to have something close to
the Class/instance systems many people think they are familiar with,
then that's possible, but you need to do it yourself, and from what
I've seen, many people do not actually have a good enough mental model
of either prototyping or classes or both to pull it off. Anyway I'd
definitely skip discussions of classes etc to the end of your text.

The other terms and necessary - if necessary - alternatives can be
discussed as it goes.


The introspection as like: http://en.wikipedia.org/wiki/Introspection_(computer_science)
?

Well, yeah, a bit. Actually the word I was looking for was
"Reflection". Basically, I don't think Java has enough "meta"
programming functionalities to pull off the example below.

This is a particular case of the method augmentation. As I said
before
(http://groups.google.com/group/comp.lang.javascript/msg/
6e2d3d616109b87c) :
" this.method = new Function(args, code);
will not have state in any case unless a secondary function
augmentation which is kind of out of subject right now"

All that depends on what is in the variable "code". Also, I really
don't understand what you mean with "secondary function augmentation".

The above applies as well to the secondary augmentation of shared
stateless methods: it is possible, sometimes used, but it has very
weak relation with OOP matters. If we straighten up all this stuff
then it comes to something simple like:

var extraStorage = {};

function MyObject(key) {
this.key = key;
extraStorage[key] = this;
}
MyObject.prototype = function() {
// do with extraStorage[this.key];
}

Well, maybe, but did you really mean to make MyObject.prototype a
function? I can't help but think that you're not making things as
clear as you could.

Other words these are the same owned (per instance) methods just
"outsourced" for whatever reason over shared method used as some kind
of interface.
What?


I am not sure I was using "per-object state" and "per-class state"
terms pair. When using "state" or "stateless" I am referring to the
state of a method in application to an object instance: say each
instance has its own Counter variable in its method and its value may
be different for each instance at once. Therefore "per-class state" is
not bearing too much sense to me.

I meant that the state could be shared too, just like the methods.

Unless you are talking about derived
classes over mutable constructors,

I wasn't.

I am not satisfied at all by existing Javascript inheritance articles.
The amount of strange code samples and questions like "what a hey
prototype is?!" suggest that many Javascript beginners do not get them
as well. IMHO 99% of existing materials can be divided in two groups.
One is "canonical", where slightly altered quotations from ECMAScript
docs are illustrated by one-two samples. Normally readers are leaving
such articles with the knowledge that "Javascript doesn't have
classes, it is prototype based" - thus one obscure sentence more than
they knew before start reading such article, so even lesser than
before

You can't make it better by ignoring prototypes.

I would really like to stay in the middle. So are closures, mutable
constructors, constructor != function constructor etc. possible? Yes,
of course. But let's hold the breath till the appropriate moment for
that ;-)

Sure. So do that then.

Let's us finish with the basic terms and pure prototype inheritance
first.
Agreed.


The body of what? Do you mean the outer function?

The body as in the variable "body".

In this case your understanding of the nature of the closure is not
full so far. Again, in my sample "a lot of data" doesn't necessary
mean a string literal "a lot of data". _Anything_ being stoke in a
closure never released unless manually cleared out.

I would consider any implementation that does that to be a very lazy
one. But I don't know what you mean by "being stoke in a closure", and
for all I know all current JS interpreters are lazy.

Also, copying a reference to an object does not equal making copies of
the object.

This is why once a
while ago I said that using closures is like sending Devil to do the
job. It may do exactly what you want but the price may be high and the
most unexpected one.
A "contract" to think over at your spare time:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Proto : 1</title>
<script type="text/javascript">

function MyObject(data) {
this.propertyOne = function(){
eval("window.alert(data)");
};
}

var obj = [1,2,3];

var myInstance = new MyObject(obj);

var obj = null;

window.setTimeout("myInstance.propertyOne()",1000);
</script>
</head>
<body>
<p>No content</p>
</body>
</html>

What is this supposed to prove, except that one shouldn't use eval()
if you can avoid it?

Again, your understanding of _documented_ and expected closure
mechanics in Javascript needs more improvement.

Probably. Or maybe the implementations just aren't good enough.

 

[VK]

The only really interesting way to share methods in JS is by
inheritance. IOW all you really need to explain here is methods as
properties of an object vs methods as properties of a prototype of an
object. You only need 2 examples for that and your four examples and
slightly confusing terminology are not making things clearer.

IMHO before explaining how to do things it is useful to explain why to
bother to do these things.

You need to explain only a couple of things at this point:

1. functions are objects in their own right which means they can be
copied.
OK

2. objects are just bags of properties with associated values.
OK

3. methods are properties who's values are functions.
OK

4. some general hint that an object's prototype is consulted for
"missing" properties (which you may or may not call inheritance).

And - very important and mostly not understood at the beginning - the
relation of
someConstructor.prototype = something;
and instances got over someConstructor.
Other words that the object which is assigned to the prototype
property of the constructor is the prototype of the instance, not of
the constructor itself. The basics of this little know basic IMHO best
explained by Eric Lippert at http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx

And leave out any discussion state etc till after you've explained
this. You're making things appear much more confusing than they
actually are.

We need to bring people to the idea of encapsulation and closures as
the way to accomplish it in Javascript. But you must be right, maybe I
took too much of tempo.

My take on these terms is that in JS, the basic mechanism is
inheritance via prototypes (*not* templates). People *need* to get
that into their heads first.

Get what? ;-)

"prototype
1. the original or model on which something is based or formed;
pattern.
2. someone or something that serves as a typical example of a class;
model; exemplar"
(Random House Webster's, NY, 1998)

This is exactly or roughly what prototype will be for a person
starting to learn Javascript. And you want to jump on him/her right
away screaming aloud "Don't say class! Say prototype! There are no
classes, there are only prototypes!!" You may make him scared but
hardly learned anything clearly. For _you_ "a prototype" has a special
Javascript-specific meaning, just like "a class" for C++ or Java
programmer, but not for a random reader. So let's use a term that
neither implying some language-specific paradigm nor too obscure or
too technical to be understood by an average speaker.
"a template", "a model", "an exemplar" are all good in this aspect
IMHO

If you want to have something close to
the Class/instance systems many people think they are familiar with,
then that's possible, but you need to do it yourself, and from what
I've seen, many people do not actually have a good enough mental model
of either prototyping or classes or both to pull it off. Anyway I'd
definitely skip discussions of classes etc to the end of your text.

exactly what I said just a bit above.

Well, yeah, a bit. Actually the word I was looking for was
"Reflection". Basically, I don't think Java has enough "meta"
programming functionalities to pull off the example below.

Ah, OK.

All that depends on what is in the variable "code".

Also, I really
don't understand what you mean with "secondary function augmentation".

functionUsedAsMethod.extraProperty = someInstanceRelatedProperty;

But it really may wait till other types of OOP coding as I see it now.
Let's us finish with the prototype first.

The above applies as well to the secondary augmentation of shared
stateless methods: it is possible, sometimes used, but it has very
weak relation with OOP matters. If we straighten up all this stuff
then it comes to something simple like:

var extraStorage = {};

function MyObject(key) {
this.key = key;
extraStorage[key] = this;
}
MyObject.prototype = function() {
// do with extraStorage[this.key];
}

Well, maybe, but did you really mean to make MyObject.prototype a
function? I can't help but think that you're not making things as
clear as you could.

Oops...

MyObject.prototype.sharedMethod = function() {
// do with extraStorage[this.key];
}
of course - or another method name, but not an assignment to the
prototype itself. My omission typo.

What?

You still have a designated storage place to keep hash-like structured
info for each separate instance. The difference is that instead of "N
instances - N method clones - N states" you have "N instances - one
shared method - N instance specific records accessible from the shared
method by checking against the current 'this' value". This is why I
said - possibly in a bit obscure way - "over shared method used as
some kind of interface".

I would consider any implementation that does that to be a very lazy
one.

"Lazy" is not very good word here. The memory is not released not
because all references are removed but the gc is too lazy or too slow
to release it. It is exactly because the references are _not_ removed
and will not be removed as long as the closure itself exists. This
behavior is by design and by specs.

But I don't know what you mean by "being stoke in a closure"

"being enclosed by a closure", "being closed by closure"

Also, copying a reference to an object does not equal making copies of
the object.

Pay attention to the last (array) sample. For sake to a further
surprise feel free to set timeout instead of 1sec to 10sec or even 1
hr to "enjoy" the stability of the result. Again: it is by specs and
by design - and something what 90% of commercial developers having no
clue about. So feel yourself "involved to the secrets of the
Universe" .

function MyObject(data) {
this.method = function() {
eval('window.alert(data)');
};
}

var a = 2;
var obj1 = new MyObject(a);
a = 4;
obj1.method(); // 2

var b = 'abc';
var obj2 = new MyObject(b);
b = 'def';
obj2.method(); // 'abc';

var c = [1,2,3];
var obj3 = new MyObject(c);
c.push(4);
obj3.method(); // 1,2,3,4; but:
c = null;
window.setTimeout('obj3.method()',1000);

This is why once a
while ago I said that using closures is like sending Devil to do the
job. It may do exactly what you want but the price may be high and the
most unexpected one.
A "contract" to think over at your spare time:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<title>Proto : 1</title>
<script type="text/javascript">

function MyObject(data) {
this.propertyOne = function(){
eval("window.alert(data)");
};
}

var obj = [1,2,3];

var myInstance = new MyObject(obj);

var obj = null;

window.setTimeout("myInstance.propertyOne()",1000);
</script>
</head>
<body>
<p>No content</p>
</body>
</html>

What is this supposed to prove, except that one shouldn't use eval()

eval is used in samples only and exclusively to avoid possible
misinterpretation as if closure values are retained because explicitly
referenced in the closure's body. So it was moved into string literal
executed using eval().

Now the bonus question: does it help to release memory if we remove
any named argument:

function MyObject() {
this.method = function() {};
}

The right answer is "no", it doesn't help. Any argument value sent to
MyObject still retained (enclosed) over arguments[n]

 

[John G Harris]

On Sun, 15 Jun 2008 at 02:12:06, in comp.lang.javascript, VK wrote:

The problem lies in the
ambiguous nature of the term "static" in different programming
languages.

<snip>

Surely the key feature of a 'static' function is that its code doesn't
use the 'this' keyword. As a result, the function's action is not tied
to any particular instance. This is so regardless of whether the
function object is a property of an instance, a prototype object, or
neither.

John

 

[VK]

On Sun, 15 Jun 2008 at 02:12:06, in comp.lang.javascript, VK wrote:



  <snip>

Surely the key feature of a 'static' function is that its code doesn't
use the 'this' keyword. As a result, the function's action is not tied
to any particular instance. This is so regardless of whether the
function object is a property of an instance, a prototype object, or
neither.

"The symbol of rose has gotten so many different meanings that it
doesn't have any meaning any more whatsoever."
Umberto Eco, The Name of the Rose


I say that "static" is the rose of the programming: among C, C++, Java
and VB it has so many completely different meanings that it is better
to consider it just as a tradition supported frequently used acronym
keyword consisting of the sequence of six character "static". That is
IMO the only universal meaning one can define universally, without
going into description of a particular programming language. This is
why "shared" vs. "owned" is the only alternative IMHO.

 

[John G Harris]

"The symbol of rose has gotten so many different meanings that it
doesn't have any meaning any more whatsoever."
Umberto Eco, The Name of the Rose

A girl named Rose wouldn't agree. If someone says "Hello, Rose" then it
has a great deal of meaning to her.

I say that "static" is the rose of the programming: among C, C++, Java
and VB it has so many completely different meanings that it is better
to consider it just as a tradition supported frequently used acronym
keyword consisting of the sequence of six character "static". That is
IMO the only universal meaning one can define universally, without
going into description of a particular programming language.

'static', and other re-used keywords, have different meanings in
different contexts. The compiler never gets confused about the meaning;
some of the feebler programmers get confused, but they shouldn't.

Even in javascript, '+' means addition, concatenation, etc. Programmers
who object to this should remember that for Unary numbers addition *is*
concatenation. E.g ii + ii is indeed equal to iiii.

(And yes, there are Unary numbers).

This is
why "shared" vs. "owned" is the only alternative IMHO.

Before you invent a name you need to be very clear about what kind of
function you're talking about. My guess is that you're talking about
functions that don't use the current 'this' value.

Sharing and owning, with their ordinary meanings, are just
implementation details for this kind of function. Using these words
would be just as arbitrary and confusing as using 'static'.

John