Primitives vs objects in protototype

Discussion in 'Javascript' started by optimistx, Oct 18, 2009.

  1. optimistx

    optimistx Guest

    I have had mysterious errors when trying to use prototypes. Sometimes the
    values change as expected and sometimes not.

    E.g. A is the constructor of object a1, which is the prototype of
    constructor B.
    b1 and b2 are objects created by B.

    I had learned that properties in b1 and b2 inherited from a1 are 'read
    only'. and writing to them creates a new own property in the objects b1 and
    b2. Nice, properties in a1 act like default values for properties in b1 and
    b2.

    But when a1 has composite variables as properties the above is not true! One
    can write to 'prototype variables' after object creation and they change for
    ALL objects inherited from them.

    An example:

    var SES = SES || {};

    SES.A = function () {
    this.prim = 'this.primitive';
    this.obj = {key1: 'key1 value in obj'};
    }

    SES.B = function () {
    }

    SES.doit = function () {
    var a1, b1, b2;

    a1 = new SES.A();
    SES.B.prototype = a1;

    b1 = new SES.B();
    b2 = new SES.B();
    b1.obj.key1 = 'b1.obj.key1';
    b1.prim = 'b1.prim';

    alert(b2.prim); //'this.primitive': b2.prim was not changed, when b1.prim
    was
    alert(b2.obj.key1); // 'b1.obj.key1' : b2.obj.key was changed, when
    b1.obj.key was ***
    };


    SES.init = function () {
    SES.doit();
    };

    window.onload = SES.init;

    Actually this should be as trivial as using primitive versus composite
    variables as function arguments: primitives are actually copied to the
    function, but other variables have only their reference ('pointer',
    'address' ) copied, not the actual values. And this has consequences :)

    Do you know some patterns, principles, where one has used these features in
    prototypes?

    Prototypes feel very intriguing, exciting, and in a way simple compared to
    classes and objects in other languages. Or is this whole idea of prototypes
    a fad, a nice theoretically elegant feature without much value in practical
    programming?(like recursion). E.g. Crockford has written his JSON-routines
    to handle only object's own properties! Jslint recommends to filter away all
    the properties except own in any for..in - loop. So forget prototypes? Or
    is there any practical use after all?
     
    optimistx, Oct 18, 2009
    #1
    1. Advertising

  2. optimistx

    VK Guest

    On Oct 19, 12:04 am, "optimistx" wrote:
    > Do you know some patterns, principles, where one has used these features in
    > prototypes?


    The only worth to mention source on the prototype inheritance I
    managed to find over these years is Eric Lippert's blog article of
    2003 "The JScript Type System, Part Two: Prototypes and
    constructors" (Eric Lippert is the guy who originally made JScript
    engine for IE and a very interesting writer atop of it which is not so
    often among programmers).
    The rest of hundreds and hundreds sources I went through is a boring
    bs: the same C/Java-grounded neophyte is forced to or is paid to write
    about things he/she hates to the very deep of the soul. - So the text
    looks like a Christian missionary trying to describe and to explain
    voodoo ceremonies :)

    http://blogs.msdn.com/ericlippert/archive/2003/11/06/53352.aspx
    also
    http://groups.google.com/group/comp..._frm/thread/a0747f4385c4e343/aaf9e3d81bf0b4ed
     
    VK, Oct 18, 2009
    #2
    1. Advertising

  3. optimistx

    Henry Guest

    On Oct 18, 9:04 pm, optimistx wrote:
    > I have had mysterious errors when trying to use prototypes.
    > Sometimes the values change as expected and sometimes not.
    >
    > E.g. A is the constructor of object a1, which is the prototype
    > of constructor B.
    > b1 and b2 are objects created by B.
    >
    > I had learned that properties in b1 and b2 inherited from a1 are
    > 'read only'. and writing to them creates a new own property in the
    > objects b1 and b2. Nice, properties in a1 act like default values
    > for properties in b1 and b2.
    >
    > But when a1 has composite variables as properties


    There are no such tings as "composite variables" in javascript. A
    variable, or a property of an object (variables being properties of
    objects) can, and any one time, have precisely one value. That value
    is either a primitive value or a 'reference' to an object.

    > the above is not true!


    Very little is going to be true when the subject of discussion is
    fictional.

    > One can write to 'prototype variables'


    If you mean write a value to the property of an object that is a
    prototype, it would be better to say so.

    > after object creation and they change for
    > ALL objects inherited from them.
    >
    > An example:
    >
    > var SES = SES || {};


    If you don't understand what you are doing why are you introducing
    this entire layer of superfluous complexity? All it is going to do is
    get in the way of your understanding what you are doing.

    > SES.A = function () {
    > this.prim = 'this.primitive';
    > this.obj = {key1: 'key1 value in obj'};
    >
    > }
    >
    > SES.B = function () {
    >
    > }
    >
    > SES.doit = function () {
    > var a1, b1, b2;
    >
    > a1 = new SES.A();
    > SES.B.prototype = a1;
    >
    > b1 = new SES.B();
    > b2 = new SES.B();
    > b1.obj.key1 = 'b1.obj.key1';

    ^^^^^^^^
    This is writing to a property of an object that is 'referred to' by a
    property of the object that is the [[Prototype]] of - b1 -.

    > b1.prim = 'b1.prim';
    >
    > alert(b2.prim); //'this.primitive': b2.prim was not changed, when b1.prim
    > was
    > alert(b2.obj.key1); // 'b1.obj.key1' : b2.obj.key was changed, when
    > b1.obj.key was ***


    Both of - b1.obj - and - b2.obj - have the same value, the same
    inherited reference to an object. If you change the value of a
    property of the object referred to then the value of that property of
    that object will have changed, but both the references to that object
    will not have changed value.

    > };
    >
    > SES.init = function () {
    > SES.doit();
    >
    > };
    >
    > window.onload = SES.init;
    >
    > Actually this should be as trivial as using primitive versus
    > composite variables


    You mean as trivial as the difference between using something that
    does exist in the language and something that doesn't?

    > as function arguments: primitives are actually copied to the
    > function,


    How could you possibly tell?

    > but other variables have only their reference ('pointer',
    > 'address' ) copied,


    There are no means (short of examining specific implementation source
    code) of determining that primitives are not handled in exactly that
    way. Remember that javascript includes no mechanism that is capable of
    changing a primitive value. Assignment of a primitive value, for
    example, replaces one value of a property with another. The first
    value is not modified by that action.

    > not the actual values. And this has consequences :)
    >
    > Do you know some patterns, principles, where one has used these
    > features in prototypes?


    What is that supposed to mean? Understanding how things work is the
    best guide for getting things to behave the way you want them to.

    > Prototypes feel very intriguing, exciting, and in a way simple
    > compared to classes and objects in other languages. Or is this
    > whole idea of prototypes a fad, a nice theoretically elegant
    > feature without much value in practical programming?(like recursion).


    No (or yes).

    > E.g. Crockford has written his JSON-routines to handle only
    > object's own properties! Jslint recommends to filter away all
    > the properties except own in any for..in - loop. So forget
    > prototypes? Or is there any practical use after all?


    Memory use and object instantiation performance in javascript relate
    very closely to the use of prototypes.

    It is pretty silly to start attempting to dismiss things that you
    don't understand. Understanding prototypes will answer all related
    questions.

    Richard.
     
    Henry, Oct 18, 2009
    #3
  4. optimistx

    optimistx Guest

    Henry wrote:
    > On Oct 18, 9:04 pm, optimistx wrote:

    ....
    >> But when a1 has composite variables as properties

    >
    > There are


    You have done a considerable amount of work to answer my post and
    I appreciate that.

    I feel your tone in the answer interesting. In case you might be
    interested in my feelings pls go ahead. In other case you can STOP HERE.

    First of all, feelings, human relations, politeness, friendliness are not
    part of javascript and therefore might be off topic here.

    Being off topic might be another reason to STOP HERE, and preferably
    put my writings to a killfile now.

    As an exercise in human interactions, I would like to express in
    in my own words (vs copying your words), what I understood you to
    probably say. I might comment and answer later but not in this entry.


    >no such tings as "composite variables" in javascript. A
    > variable, or a property of an object (variables being properties of
    > objects) can, and any one time, have precisely one value. That value
    > is either a primitive value or a 'reference' to an object.


    I hear you telling me that instead of "composite variables" I should have
    written " 'references' to objects".

    >
    >> the above is not true!

    >
    > Very little is going to be true when the subject of discussion is
    > fictional.


    I feel that you are very annoyed about my unprofessional usage
    of words. You say that the topic of my entry is not real,
    it is in the imaginative world only.


    >
    >> One can write to 'prototype variables'

    >
    > If you mean write a value to the property of an object that is a
    > prototype, it would be better to say so.


    You are not sure what I meant, and guessed one possibility
    expressing that in your words. If the guess were true,
    you wished that I had been as expertlike in
    using words as you are, and used the same expression as you.

    >
    >> after object creation and they change for
    >> ALL objects inherited from them.
    >>
    >> An example:
    >>
    >> var SES = SES || {};

    >
    > If you don't understand what you are doing why are you introducing
    > this entire layer of superfluous complexity? All it is going to do is
    > get in the way of your understanding what you are doing.


    You assume that possibly I do not understand what the expression
    var SES = SES || {} is doing.

    You ask me, why I added the above to the example. You do not
    consider it useful. You consider it unnecessary and difficult to
    understand, not simple.
    You think that due to the above I do not understand the example. If
    I had not used the above, I might have understood.

    >
    >> SES.A = function () {
    >> this.prim = 'this.primitive';
    >> this.obj = {key1: 'key1 value in obj'};
    >>
    >> }
    >>
    >> SES.B = function () {
    >>
    >> }
    >>
    >> SES.doit = function () {
    >> var a1, b1, b2;
    >>
    >> a1 = new SES.A();
    >> SES.B.prototype = a1;
    >>
    >> b1 = new SES.B();
    >> b2 = new SES.B();
    >> b1.obj.key1 = 'b1.obj.key1';

    > ^^^^^^^^
    > This is writing to a property of an object that is 'referred to' by a
    > property of the object that is the [[Prototype]] of - b1 -.


    With other words, the last statement above is storing
    a value to a memory location,
    whose reference is in a property of the prototype of b1.
    You reword what my code says.

    >
    >> b1.prim = 'b1.prim';
    >>
    >> alert(b2.prim); //'this.primitive': b2.prim was not changed, when
    >> b1.prim was
    >> alert(b2.obj.key1); // 'b1.obj.key1' : b2.obj.key was changed, when
    >> b1.obj.key was ***

    >
    > Both of - b1.obj - and - b2.obj - have the same value, the same
    > inherited reference to an object. If you change the value of a
    > property of the object referred to then the value of that property of
    > that object will have changed, but both the references to that object
    > will not have changed value.


    You say essentially the same as I say, using your own, more exact words.

    >
    >> };
    >>
    >> SES.init = function () {
    >> SES.doit();
    >>
    >> };
    >>
    >> window.onload = SES.init;
    >>
    >> Actually this should be as trivial as using primitive versus
    >> composite variables

    >
    > You mean as trivial as the difference between using something that
    > does exist in the language and something that doesn't?


    You feel that I should not use in these discussions my own
    words and general purpose English. I should use
    exactly the words which you use or ECMAScript-262
    define.

    >
    >> as function arguments: primitives are actually copied to the
    >> function,

    >
    > How could you possibly tell?


    You are asking, how I know that primitives are copied to a
    function. I understand you infering, that if a primitive is
    a function argument, it either is not copied to the function,
    or in some situations it is, some others it is not:

    var a = 1;
    function f(arg){arg++}
    f(a);
    alert(a) // if copy, alert shows 1, if not copy, alert shows 2

    >
    >> but other variables have only their reference ('pointer',
    >> 'address' ) copied,

    >
    > There are no means (short of examining specific implementation source
    > code) of determining that primitives are not handled in exactly that
    > way. Remember that javascript includes no mechanism that is capable of
    > changing a primitive value. Assignment of a primitive value, for
    > example, replaces one value of a property with another. The first
    > value is not modified by that action.


    I understand you saying that if
    var a = 1;
    a = 2;
    then the primitive variable value a is not changed from 1 to 2.
    Further, if a is a property of object o with primitive value,
    var o.a = 3;
    o.a = 4;
    then o.a is not changed from 3 to 4


    >
    >> not the actual values. And this has consequences :)
    >>
    >> Do you know some patterns, principles, where one has used these
    >> features in prototypes?

    >
    > What is that supposed to mean? Understanding how things work is the
    > best guide for getting things to behave the way you want them to.


    You do not understand my question.You recommend (me) to increase
    (my) understanding. Then my programs behave as I want.

    >
    >> Prototypes feel very intriguing, exciting, and in a way simple
    >> compared to classes and objects in other languages. Or is this
    >> whole idea of prototypes a fad, a nice theoretically elegant
    >> feature without much value in practical programming?(like recursion).

    >
    > No (or yes).


    You say no, prototypes is not a fad, or it might be. You consider the
    question unclear and give therefore an unclear answer.

    >
    >> E.g. Crockford has written his JSON-routines to handle only
    >> object's own properties! Jslint recommends to filter away all
    >> the properties except own in any for..in - loop. So forget
    >> prototypes? Or is there any practical use after all?

    >
    > Memory use and object instantiation performance in javascript relate
    > very closely to the use of prototypes.


    One can use less memory with prototypes and use less cpu-time.

    >
    > It is pretty silly to start attempting to dismiss things that you
    > don't understand.


    You assume that I start dismissing prototypes therefore that I do not
    understand them. You understand them. My behaviour is SILLY.

    >Understanding prototypes will answer all related
    > questions.


    Acquire understanding somewhere, somehow, and do not bother
    me with SILLY questions.
    >
    > Richard.


    As in any human and even machine communication there are
    possibilities for errors. Therefore
    a method of sending a receipt with one's own words (might be
    useful method to find the missunderstandings and continue
    discussion around a clean table, if there is mutual desire to do so.)
     
    optimistx, Oct 20, 2009
    #4
  5. optimistx

    Jorge Guest

    On Oct 20, 5:11 pm, "optimistx" <> wrote:
    >
    > (...)
    >


    This might help, I think:

    a= 1; // a primitive value
    b= a;
    c= a;
    alert([a,b,c]); // -> [1, 1, 1]
    c= 27;
    alert([a,b,c]); // -> [1, 1, 27]

    a= {n: 1}; // a reference to the object {n: 1}
    b= a;
    c= a;
    alert([a.n, b.n, c.n]); // -> [1, 1, 1]
    c.n= 27;
    alert([a.n, b.n, c.n]); // -> [27, 27, 27]

    Do you see why ?

    --
    Jorge.
     
    Jorge, Oct 20, 2009
    #5
  6. optimistx

    optimistx Guest

    Jorge wrote:
    > On Oct 20, 5:11 pm, "optimistx" <> wrote:
    >>
    >> (...)
    >>

    >
    > This might help, I think:

    Thanks, let us see. With my own words, on purpose in a different way:
    >
    > a= 1; // a primitive value

    memory location called a contains a constant number 1 after the assignment
    > b= a;

    the contents of memory location called a is copied to memory location b
    (assume b is not the same address as a)
    > c= a;

    the contents of memory location a is copied to memory location c. After
    these assignments the memory in question contains number 1 in 3 different
    locations.
    > alert([a,b,c]); // -> [1, 1, 1]

    as expected from the above
    > c= 27;

    in memory location c the previous contens of 1 is replaced with number 27,
    but locations a and b are not changed, they sit there tightly keeping their
    contents of 1, each.
    > alert([a,b,c]); // -> [1, 1, 27]

    as expected!
    >
    > a= {n: 1}; // a reference to the object {n: 1}

    yes, a is like a pointer, or address in other languages. Object {n:1}
    contains one own property named n, and its value (contents) is number 1
    > b= a;

    the memory location b contains now the contents of a. With other words, both
    locations a and b
    contain the reference to the object {n:1} (which object has no name or
    identifier!)
    > c= a;

    the memory location c contains now the same contents as a and b, the
    reference (or address, or pointer) to the unnamed object {n:1}

    > alert([a.n, b.n, c.n]); // -> [1, 1, 1]

    as expected. E.g. we read the property n of unnamed object {n:1} using 3
    different references (
    pointers, addresses) to the same one object in memory, containing number 1
    in its property n
    > c.n= 27;

    the property n value (1) in our unnamed one object is changed to the value
    27. Previous value is lost. The memory locations a and b are sitting happily
    there and staring the show with their eyes round in wonder.
    > alert([a.n, b.n, c.n]); // -> [27, 27, 27]

    Yahoo! Everything as expected. Let us celebrate. Life is wonderful! It would
    be nice to draw the cases as picture also.
    >
    > Do you see why ?


    What do you think? When telling things with other words the errors in
    thinking are revealed better than repeating everything exactly as the
    teacher or specs said.

    Thanks for the exercise. It was a pleasure to look at it.
     
    optimistx, Oct 20, 2009
    #6
  7. optimistx

    Jorge Guest

    On Oct 20, 11:46 pm, "optimistx" <> wrote:
    > (..)
    > What do you think?


    A+

    Then you also know why you were having "problems" with the prototypes.

    > When telling things with other words the errors in
    > thinking are revealed better than repeating everything exactly as the
    > teacher or specs said.
    >
    > Thanks for the exercise. It was a pleasure to look at it.


    You're welcome.
    --
    Jorge.
     
    Jorge, Oct 20, 2009
    #7
  8. optimistx

    Henry Guest

    optimistx wrote:
    > Henry wrote:
    >> On Oct 18, 9:04 pm, optimistx wrote:

    > ...
    >>> But when a1 has composite variables as properties

    >>
    >> There are

    >
    > You have done a considerable amount of work to answer my post and
    > I appreciate that.
    >
    > I feel your tone in the answer interesting. In case you might
    > be interested in my feelings


    Why would anyone be interested in your feelings? Reality is not
    modified by how you feel about it. That can only impact on how you
    perceive reality, and won't impact on anyone else.

    > pls go ahead. In other case you can STOP HERE.


    Keep working at it and you might achieve a situation where nobody
    bothers with your questions at all.

    > First of all, feelings, human relations, politeness, friendliness
    > are not part of javascript and therefore might be off topic here.


    Obviously, so why do you waste so many words on that subject here.

    > Being off topic might be another reason to STOP HERE, and
    > preferably put my writings to a killfile now.
    >
    > As an exercise in human interactions, I would like to express
    > in in my own words (vs copying your words),


    Fine, so long as you provide definitions for any non-javascript
    standard jargon you elect to use. Otherwise you will likely end up
    saying nothing.

    > what I understood you to probably say. I might comment and
    > answer later but not in this entry.
    >
    >> no such tings as "composite variables" in javascript. A
    >> variable, or a property of an object (variables being properties
    >> of objects) can, and any one time, have precisely one value.
    >> That value is either a primitive value or a 'reference' to an
    >> object.

    >
    > I hear you telling me that instead of "composite variables"
    > I should have written " 'references' to objects".


    Or provided a clear definition of what you mean by "composite
    variables" in this context.

    >>> the above is not true!

    >>
    >> Very little is going to be true when the subject of discussion
    >> is fictional.

    >
    > I feel that you are very annoyed about my unprofessional usage
    > of words.


    Not annoyed, just pointing out that when there is no meaning in what
    you re saying you are effectively saying nothing, which can be done
    with far fewer words.

    > You say that the topic of my entry is not real,


    Without stating the definition of the term in relation to things that
    do exist in javascript there are no "composite variable" in
    javascript, and so they are not real.

    > it is in the imaginative world only.
    >
    >>> One can write to 'prototype variables'

    >>
    >> If you mean write a value to the property of an object that
    >> is a prototype, it would be better to say so.

    >
    > You are not sure what I meant,


    I am sure that prototypes (objects in general) don't have variables
    and so that writing to a "prototype variable" has no meaning in
    itself..

    > and guessed one possibility


    I am perceiving the wide spectrum of possibilities. Picking one is the
    only way of going forward. Assuming that one possibility would not
    necessarily be valid, so questioning your meaning and waiting for
    clarification makes most sense.

    > expressing that in your words. If the guess were true,
    > you wished that I had been as expertlike in
    > using words as you are,
    > and used the same expression as you.


    Not just me, but employing the terminology that has objective meaning
    when applied to this subject.

    >>> after object creation and they change for
    >>> ALL objects inherited from them.
    >>>
    >>> An example:
    >>>
    >>> var SES = SES || {};

    >>
    >> If you don't understand what you are doing why are you introducing
    >> this entire layer of superfluous complexity? All it is going
    >> to do is get in the way of your understanding what you are doing.

    >
    > You assume that possibly I do not understand what the expression
    > var SES = SES || {} is doing.


    I don't care whether you understand it or not. It certainly is utterly
    superfluous to your question and so is more likely to get in the way
    of understanding than to achieve anything else.

    > You ask me, why I added the above to the example.


    And you are making it clear that you are not going to answer that
    question.

    > You do not consider it useful.


    The only impact removing from the example would have would be to
    simplify its presentation and ease its interpretation.

    > You consider it unnecessary and difficult to
    > understand, not simple.


    I consider it superfluous.

    > You think that due to the above I do not understand the example.


    Knowing what is relevant and what is superfluous is an indicator of
    understanding.

    > If I had not used the above, I might have understood.


    Maybe, but understanding would have suggested not including anything
    superfluous in your question.

    >>> SES.A = function () {
    >>> this.prim = 'this.primitive';
    >>> this.obj = {key1: 'key1 value in obj'};
    >>>
    >>> }
    >>>
    >>> SES.B = function () {
    >>>
    >>> }
    >>>
    >>> SES.doit = function () {
    >>> var a1, b1, b2;
    >>>
    >>> a1 = new SES.A();
    >>> SES.B.prototype = a1;
    >>>
    >>> b1 = new SES.B();
    >>> b2 = new SES.B();
    >>> b1.obj.key1 = 'b1.obj.key1';

    >> ^^^^^^^^
    >> This is writing to a property of an object that is 'referred to'
    >> by a property of the object that is the [[Prototype]] of - b1 -.

    >
    > With other words, the last statement above is storing
    > a value to a memory location,


    That is nearly meaningless in context. The odds are that an assignment
    in javascript results in values being sorted in memory locations in
    the implementation, or in the VM that runs the implementation, or at
    least somewhere, but that has little of value to say about
    javascript's behaviour.

    Consider, for example, the assignment of a numeric primitive value to
    a property of on object. In javascript terms that is probably the
    whole story (minus getters/setters and ReadOnly attributes and the
    like). For the implementation the value assigned has a type (it is a
    numeric primitives) and it has a value (a 64 bit IEEE double precision
    floating point value). From the property of the object it is necessary
    to be able to recover both the type and the value, which means that
    either the 'property' has to know the type and the value, or the
    'property' has to know where it can get at the numeric primitive and
    the numeric primitive knows both its type and value. So if assignment
    does involve writing a value to a memory location then that action is
    certainly not going to be anything as simple and direct as writhing
    the 64 bit IEEE double precision floating point value to some memory
    location.

    Also remember that javascript has been implemented in Java (Rhino) and
    JavaScript(tm) (Narcissus), and neither of those languages have any
    means of directly addressing memory locations.

    > whose reference is in a property of the prototype of b1.
    > You reword what my code says.


    Yes, because your issues appears to be not appreciating that writing a
    value to a property of an object that is not a [[Prototype]] of - b1 -
    will not result in that value being inherited.

    >>> b1.prim = 'b1.prim';
    >>>
    >>> alert(b2.prim); //'this.primitive': b2.prim was not changed,
    >>> when b1.prim was
    >>> alert(b2.obj.key1); // 'b1.obj.key1' : b2.obj.key was changed,
    >>> when b1.obj.key was ***

    >>
    >> Both of - b1.obj - and - b2.obj - have the same value, the same
    >> inherited reference to an object. If you change the value of a
    >> property of the object referred to then the value of that
    >> property of that object will have changed, but both the
    >> references to that object will not have changed value.

    >
    > You say essentially the same as I say,


    I didn't notice you saying anything, the mass of words not
    withstanding.

    > using your own, more exact words.
    >
    >>> };
    >>>
    >>> SES.init = function () {
    >>> SES.doit();
    >>>
    >>> };
    >>>
    >>> window.onload = SES.init;
    >>>
    >>> Actually this should be as trivial as using primitive versus
    >>> composite variables

    >>
    >> You mean as trivial as the difference between using something
    >> that does exist in the language and something that doesn't?

    >
    > You feel that I should not use in these discussions my own
    > words


    Not without defining them. Consider the terms; "the call object", "the
    calling object" and "the default object". All of which appear in
    writings about javascript, but in contexts that imply such a range of
    meanings that the meaning for each become mutually exclusive. Unless
    someone actually states what thy mean by, for example, "the default
    object" then they will end up saying nothing. On the other hand, a
    term like "Variable object" has such clear, specific and objective
    meaning that a statement about a "Variable object" is very likely to
    be only one a true statement or a false statement.

    > and general purpose English. I should use
    > exactly the words which you use or ECMAScript-262
    > define.
    >>
    >>> as function arguments: primitives are actually copied
    >>> to the function,

    >>
    >> How could you possibly tell?

    >
    > You are asking, how I know that primitives are copied to a
    > function.


    That was the question, and if you tried answering it you might realise
    that you cannot tell.

    > I understand you infering, that if a primitive is
    > a function argument, it either is not copied to the
    > function, or in some situations it is, some others it
    > is not:


    No, I was trying to highlight the fact that you cannot tell.

    > var a = 1;
    > function f(arg){arg++}
    > f(a);
    > alert(a) // if copy, alert shows 1, if not copy, alert shows 2


    This comment, for example, implies the notion that primitive values
    could be modified, which is not the case in javascript. In practice
    the - arg++ - replaces the value of the 'arg' property of the
    function's execution context's Variable object with another primitive
    value that is the result of adding a numeric value of one to the
    original value. This could never have any impact on the numeric
    primitive that was previously assigned to 'a' property of the global
    object.

    >>> but other variables have only their reference ('pointer',
    >>> 'address' ) copied,

    >>
    >> There are no means (short of examining specific implementation
    >> source code) of determining that primitives are not handled in
    >> exactly that way.


    Recalling that primitive values have both 'type' and a 'value'.

    >> Remember that javascript includes no mechanism that is capable
    >> of changing a primitive value. Assignment of a primitive value,
    >> for example, replaces one value of a property with another.
    >> The first value is not modified by that action.

    >
    > I understand you saying that if
    > var a = 1;
    > a = 2;
    > then the primitive variable value a is not changed from 1 to 2.


    The primitive value that has a 'type' of number and a value that is
    the IEEE double precision representation of 1 is not modified. Instead
    another primitive value that has a 'type' of number and a value that
    is the IEEE double precision representation of 2 is assigned to the -
    a - variable.

    > Further, if a is a property of object o with primitive value,
    > var o.a = 3;
    > o.a = 4;
    > then o.a is not changed from 3 to 4


    The value of the 'a' property of - o - is changed from one numeric
    primitive to a different numeric primitive.

    >>> not the actual values. And this has consequences :)
    >>>
    >>> Do you know some patterns, principles, where one has used
    >>> these features in prototypes?

    >>
    >> What is that supposed to mean? Understanding how things work
    >> is the best guide for getting things to behave the way you want
    >> them to.

    >
    > You do not understand my question.


    The question doesn't mean anything. It is just a string of jargon.

    > You recommend (me) to increase
    > (my) understanding. Then my programs behave as I want.


    In the event of knowing how you want your programs to behave,
    understanding how the language works will considerably contribute
    toward achieving that behaviour.

    >>> Prototypes feel very intriguing, exciting, and in a way
    >>> simple compared to classes and objects in other languages.
    >>> Or is this whole idea of prototypes a fad, a nice
    >>> theoretically elegant feature without much value in
    >>> practical programming?(like recursion).

    >>
    >> No (or yes).

    >
    > You say no, prototypes is not a fad, or it might be. You
    > consider the question unclear and give therefore an unclear
    > answer.
    >>
    >>> E.g. Crockford has written his JSON-routines to handle only
    >>> object's own properties! Jslint recommends to filter away all
    >>> the properties except own in any for..in - loop. So forget
    >>> prototypes? Or is there any practical use after all?

    >>
    >> Memory use and object instantiation performance in javascript
    >> relate very closely to the use of prototypes.

    >
    > One can use less memory with prototypes and use less cpu-time.
    >
    >> It is pretty silly to start attempting to dismiss things that you
    >> don't understand.

    >
    > You assume that I start dismissing prototypes


    You are the one questioning whether prototypes are a "fad".

    > therefore that I do not understand them. You understand
    > them. My behaviour is SILLY.
    >
    >> Understanding prototypes will answer all related
    >> questions.

    >
    > Acquire understanding somewhere, somehow, and do not bother
    > me with SILLY questions.

    <snip>

    Yes, questions like "Or is this whole idea of prototypes a fad ... "
    are silly and pointless in this context. Javascript has prototype
    inheritance and it really doesn't matter whether that is a god thing
    or a bad thing. They are the things that they are, they work the way
    they work, and they are not going away any time soon, so either you
    understand them or you don't ever understand javascript. And if you
    don't understand them then there are a mass of better, more useful,
    questions that could be asked instead.
     
    Henry, Oct 21, 2009
    #8
    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. George Mercury

    Instantiate primitives in for-generate?

    George Mercury, Jul 28, 2005, in forum: VHDL
    Replies:
    2
    Views:
    643
  2. Alan
    Replies:
    1
    Views:
    346
    VisionSet
    Oct 22, 2003
  3. Replies:
    12
    Views:
    721
    Chris Uppal
    May 30, 2005
  4. Adam Warner

    Covariance of Java primitives

    Adam Warner, Mar 23, 2006, in forum: Java
    Replies:
    6
    Views:
    1,862
    Adam Warner
    Mar 24, 2006
  5. Bill Medland

    Returning primitives by reference

    Bill Medland, Jul 20, 2006, in forum: Java
    Replies:
    7
    Views:
    519
    Oliver Wong
    Jul 25, 2006
Loading...

Share This Page