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]

VK wrote:

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.protot ype.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
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee

[RobG]

On Jun 15, 7:12*pm, VK <schools_r...@y ahoo.comwrote:

<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.protot ype.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.metho d" 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:

<URL: http://en.wikipedia.org/wiki/Curry_function >

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

[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 misinterpretati on 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 misunderstandin g. 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 individualizati on 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 individualizati on 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.

[Lasse Reichstein Nielsen]

VK <sc**********@y ahoo.comwrites:

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.sharedState less = 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.protot ype.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
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Joost Diepenmaat]

RobG <rg***@iinet.ne t.auwrites:

On Jun 19, 9:25 am, Joost Diepenmaat <jo...@zeekat.n lwrote:

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

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?

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/

[RobG]

On Jun 19, 8:42*pm, Joost Diepenmaat <jo...@zeekat.n lwrote:

RobG <[e-mail] t.auwrites:

[...]

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. :-(
--
Rob

[John G Harris]

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

<snip>

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

[VK]

On Jun 21, 8:09*pm, John G Harris <[e-mail] mon.co.ukwrote:

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

* <snip>>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.

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

On Sat, 21 Jun 2008 at 14:53:12, in comp.lang.javas cript, VK wrote:

>On Jun 21, 8:09*pm, John G Harris <[e-mail] mon.co.ukwrote:

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

* <snip>>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.

"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
--
John Harris