Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Terms for method types?

Reply
Thread Tools

Terms for method types?

 
 
VK
Guest
Posts: n/a
 
      06-15-2008
<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?
 
Reply With Quote
 
 
 
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      06-15-2008
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.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
--
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
 
Reply With Quote
 
 
 
 
RobG
Guest
Posts: n/a
 
      06-15-2008
On Jun 15, 7:12*pm, VK <(E-Mail Removed)> wrote:
> <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:

<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
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      06-15-2008
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.
 
Reply With Quote
 
Joost Diepenmaat
Guest
Posts: n/a
 
      06-16-2008
VK <(E-Mail Removed)> writes:

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

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
 
Reply With Quote
 
VK
Guest
Posts: n/a
 
      06-16-2008
On Jun 16, 3:55 pm, Joost Diepenmaat <(E-Mail Removed)> wrote:
> VK <(E-Mail Removed)> writes:
> > 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.


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.

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


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

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


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.

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


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.
 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      06-16-2008
VK <(E-Mail Removed)> writes:

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
--
Lasse Reichstein Nielsen - http://www.velocityreviews.com/forums/(E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Joost Diepenmaat
Guest
Posts: n/a
 
      06-18-2008

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

Anyway,

VK <(E-Mail Removed)> writes:
> On Jun 16, 3:55 pm, Joost Diepenmaat <(E-Mail Removed)> wrote:
>> VK <(E-Mail Removed)> writes:
>> > 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.

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

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


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.

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


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.

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

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

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

>
> 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");
>
>> 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(){};


what about

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

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

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


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.

--
Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
 
Reply With Quote
 
RobG
Guest
Posts: n/a
 
      06-19-2008
On Jun 19, 9:25 am, Joost Diepenmaat <(E-Mail Removed)> wrote:
[...]
> VK <(E-Mail Removed)> writes:
> > On Jun 16, 3:55 pm, Joost Diepenmaat <(E-Mail Removed)> wrote:
> >> VK <(E-Mail Removed)> writes:

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

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.

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

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


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


And if you do:

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

[...]

--
Rob
 
Reply With Quote
 
Joost Diepenmaat
Guest
Posts: n/a
 
      06-19-2008
RobG <(E-Mail Removed)> writes:

> On Jun 19, 9:25 am, Joost Diepenmaat <(E-Mail Removed)> wrote:
>> 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/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
How make a query in terms of File Index value in Inderx Server savvy ASP .Net 1 01-16-2006 03:58 PM
Asp vs ASPX pages in terms of security Patrick Olurotimi Ige ASP .Net 1 02-10-2005 08:46 PM
Laman's terms please! Lori Cole via .NET 247 ASP .Net 1 10-28-2004 09:29 PM
Network Engineer - let's define our terms! newsreader Cisco 76 09-19-2003 02:50 AM
Terms and Conditions for Exams? Matt MCSE 24 09-02-2003 04:19 PM



Advertisments