Terms for method types?

Discussion in 'Javascript' started by VK, Jun 15, 2008.

  1. VK

    VK Guest

    <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?
     
    VK, Jun 15, 2008
    #1
    1. Advertising

  2. 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
     
    Thomas 'PointedEars' Lahn, Jun 15, 2008
    #2
    1. Advertising

  3. VK

    RobG Guest

    On Jun 15, 7:12 pm, VK <> 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
     
    RobG, Jun 15, 2008
    #3
  4. VK

    VK Guest

    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.
     
    VK, Jun 15, 2008
    #4
  5. VK <> 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/
     
    Joost Diepenmaat, Jun 16, 2008
    #5
  6. VK

    VK Guest

    On Jun 16, 3:55 pm, Joost Diepenmaat <> wrote:
    > VK <> 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.
     
    VK, Jun 16, 2008
    #6
  7. VK <> 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 -
    DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
    'Faith without judgement merely degrades the spirit divine.'
     
    Lasse Reichstein Nielsen, Jun 16, 2008
    #7
  8. To start off: I'm going to quote large sections here, because I think
    this post won't make sense otherwise.

    Anyway,

    VK <> writes:
    > On Jun 16, 3:55 pm, Joost Diepenmaat <> wrote:
    >> VK <> 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/
     
    Joost Diepenmaat, Jun 19, 2008
    #8
  9. VK

    RobG Guest

    On Jun 19, 9:25 am, Joost Diepenmaat <> wrote:
    [...]
    > VK <> writes:
    > > On Jun 16, 3:55 pm, Joost Diepenmaat <> wrote:
    > >> VK <> 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
     
    RobG, Jun 19, 2008
    #9
  10. RobG <> writes:

    > On Jun 19, 9:25 am, Joost Diepenmaat <> 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/
     
    Joost Diepenmaat, Jun 19, 2008
    #10
  11. VK

    RobG Guest

    On Jun 19, 8:42 pm, Joost Diepenmaat <> wrote:
    > RobG <> writes:

    [...]
    > > 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
     
    RobG, Jun 19, 2008
    #11
  12. VK

    VK Guest

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


    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.

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


    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.

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


    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.

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

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


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

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


    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.

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


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

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


    good :)

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


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


    > 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.
     
    VK, Jun 19, 2008
    #12
  13. VK <> writes:

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


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

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

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


    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?

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

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

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


    The body as in the variable "body".

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


    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?

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


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

    --
    Joost Diepenmaat | blog: http://joost.zeekat.nl/ | work: http://zeekat.nl/
     
    Joost Diepenmaat, Jun 19, 2008
    #13
  14. VK

    VK Guest

    On Jun 19, 11:13 pm, Joost Diepenmaat <> wrote:
    > 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.

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


    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.

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

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

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


    Ah, OK.

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

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

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


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

    <snip for further reading>

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


    "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]
     
    VK, Jun 19, 2008
    #14
  15. On Sun, 15 Jun 2008 at 02:12:06, in comp.lang.javascript, 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
     
    John G Harris, Jun 21, 2008
    #15
  16. VK

    VK Guest

    On Jun 21, 8:09 pm, John G Harris <> wrote:
    > On Sun, 15 Jun 2008 at 02:12:06, in comp.lang.javascript, 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.
     
    VK, Jun 21, 2008
    #16
  17. On Sat, 21 Jun 2008 at 14:53:12, in comp.lang.javascript, VK wrote:
    >On Jun 21, 8:09 pm, John G Harris <> wrote:
    >> On Sun, 15 Jun 2008 at 02:12:06, in comp.lang.javascript, 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
     
    John G Harris, Jun 24, 2008
    #17
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Lori Cole via .NET 247

    Laman's terms please!

    Lori Cole via .NET 247, Aug 29, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,677
    bruce barker
    Oct 28, 2004
  2. Patrick Olurotimi Ige

    Asp vs ASPX pages in terms of security

    Patrick Olurotimi Ige, Feb 10, 2005, in forum: ASP .Net
    Replies:
    1
    Views:
    867
    Scott Allen
    Feb 10, 2005
  3. savvy
    Replies:
    1
    Views:
    418
    savvy
    Jan 16, 2006
  4. Naveen Reddy

    Thinking in terms of Objects.

    Naveen Reddy, Jan 24, 2004, in forum: Java
    Replies:
    14
    Views:
    1,313
    paul brown
    Feb 2, 2004
  5. Dung Ping

    Terms in statistics

    Dung Ping, Mar 26, 2006, in forum: HTML
    Replies:
    2
    Views:
    360
    Dung Ping
    Mar 26, 2006
Loading...

Share This Page