Questions about memory structure of value types and reference types

Discussion in 'Javascript' started by Sam Kong, Oct 12, 2006.

  1. Sam Kong

    Sam Kong Guest

    Hi,

    JavaScript hides its memory structure.
    I know that numbers, booleans, null and undefined are value types
    (value is directed saved in a variable).

    I want to know:

    - How JavaScript distinguishes value types from reference types by
    seeing the variable content?

    - How many bytes are allocated in memory when I declare the following?
    var i;


    I can program in JavaScript without understanding them.
    But I'm curious.

    Thanks.

    Sam
     
    Sam Kong, Oct 12, 2006
    #1
    1. Advertising

  2. In article <>, Sam
    Kong <> writes
    >Hi,
    >
    >JavaScript hides its memory structure.
    >I know that numbers, booleans, null and undefined are value types
    >(value is directed saved in a variable).
    >
    >I want to know:
    >
    >- How JavaScript distinguishes value types from reference types by
    >seeing the variable content?
    >
    >- How many bytes are allocated in memory when I declare the following?
    >var i;
    >
    >
    >I can program in JavaScript without understanding them.
    >But I'm curious.


    A javascript engine can be programmed any way that works.

    Your guesses are probably as good as ours.

    John
    --
    John Harris
     
    John G Harris, Oct 14, 2006
    #2
    1. Advertising

  3. Sam Kong

    VK Guest

    Sam Kong wrote:
    > JavaScript hides its memory structure.


    It doesn't officially expose it to the language tools, that would be
    more correct to say :) - but yes, it hides it.

    > I know that numbers, booleans, null and undefined are value types
    > (value is directed saved in a variable).


    That is hardly possible in a loosely typed language.
    When you declare
    var myVar;
    the engine has no idea what data will be stored in myVar; even if you
    instantiate and assign a value to it right away:
    var myVar = true;
    then it improves the code readability but it doesn't help too much to
    the engine, because right the next statement can change the data type:
    var myVar = true;
    myVar = new Object; // or something else
    (The right above is not a good way of course to benefit from the loose
    typing: yet the engine has to be ready for such flip around at any
    system tick for any variable).

    That is the end of generic considerations for *a* script engine:
    further it is the question of how *this* engine or *that* engine is
    dealing with the challenge.

    > - How JavaScript distinguishes value types from reference types by
    > seeing the variable content?
    > - How many bytes are allocated in memory when I declare the following?
    > var i;


    I'm not ready to comment on the Gecko engine. In the old Netscape (very
    fragmentary described in this aspect in ECMAScript specs) and in all
    versions of Internet Explorer it is solved by creating a structure of a
    kind of a database record with a MEMO field. So it's a fixed size
    structure yet able to keep proprietary long data in it by having it
    outside of the record and only referenced in the record itself.

    So say Internet Explorer on statement
    var i;
    internally creates new VARIANT object (not that Variant which is in
    VBA, but that VARIANT which is VT in C++)
    This VARIANT object has a data member for the value (this is an
    anonymous C++ union) and a data member indicating the type of
    information stored in the union. That is why I used the analogy with a
    database record / MEMO field (and surely made very upset all
    professional C++ programmers :)
    This VARIANT object also has data member with pointer to IDispatchEx
    interface extending the base IDispatch interface: that lets your object
    to be a reference to something else or to be a member of some other
    object.
    It also has a data member with flag set by Garbage Collector. Once for
    a while Garbage Collector comes, studies the object and if no in-scope
    references found, it raises this flag ("that is a garbage to remove").

    There is a few other fields (like a pointer to IUnknown), but the above
    members are the most essential for the core functionality.

    All this structure in application to the script engine is called
    scavenger, and it is not to mix with a heap, because the value itself
    is not here but only referenced to.

    (The mythological "native ECMAScript object with internal [[values]]"
    is an allegoric decription of the scavenger in the way of how ECMA's
    free-lancers saw it in 1999 on Netscape 4.x).

    >From this point forward your variable is ready to be whatever

    programmer's unlimited fantasy :) will make it be at any moment: a
    primitive value, an object reference, a function, an object member - it
    will not catch the engine on cold.

    The byte-exact size of the structure depends on the current OS and on
    the bit-base of the OS (16bit, 32bit, 64bit). You may look at C++ specs
    for VARIANT to find out.

    If you are really interested in the "night life" of the JScript engine
    and if you have some knowledge of C++ programming, search MSDN for
    IDispatch and IDispatchEx methods. Then you can write an util to
    connect to the engine to see scavengers appearing, GC roaming from
    scavenger to scavenger, references changing, the garbage removed.

    P.S. JScript description above is not directly applicable to
    JScript.NET
    The latter is a rather different beast.

    P.P.S. From the optimization point of view it is tempting to create at
    least short-living primitive values as just primitive values in hope to
    the programmer's reasonnable behavior; and in case of type change
    dereference the primitive and and to create a VARIANT with the same
    name. A pure speculation from my side but maybe such mechanics is
    implemented in some engines.
     
    VK, Oct 14, 2006
    #3
  4. Sam Kong

    Sam Kong Guest

    Hi VK,

    VK wrote:
    > Sam Kong wrote:
    > > JavaScript hides its memory structure.

    >
    > It doesn't officially expose it to the language tools, that would be
    > more correct to say :) - but yes, it hides it.
    >
    > > I know that numbers, booleans, null and undefined are value types
    > > (value is directed saved in a variable).

    >
    > That is hardly possible in a loosely typed language.
    > When you declare
    > var myVar;
    > the engine has no idea what data will be stored in myVar; even if you
    > instantiate and assign a value to it right away:
    > var myVar = true;
    > then it improves the code readability but it doesn't help too much to
    > the engine, because right the next statement can change the data type:
    > var myVar = true;
    > myVar = new Object; // or something else
    > (The right above is not a good way of course to benefit from the loose
    > typing: yet the engine has to be ready for such flip around at any
    > system tick for any variable).
    >
    > That is the end of generic considerations for *a* script engine:
    > further it is the question of how *this* engine or *that* engine is
    > dealing with the challenge.
    >
    > > - How JavaScript distinguishes value types from reference types by
    > > seeing the variable content?
    > > - How many bytes are allocated in memory when I declare the following?
    > > var i;

    >
    > I'm not ready to comment on the Gecko engine. In the old Netscape (very
    > fragmentary described in this aspect in ECMAScript specs) and in all
    > versions of Internet Explorer it is solved by creating a structure of a
    > kind of a database record with a MEMO field. So it's a fixed size
    > structure yet able to keep proprietary long data in it by having it
    > outside of the record and only referenced in the record itself.
    >
    > So say Internet Explorer on statement
    > var i;
    > internally creates new VARIANT object (not that Variant which is in
    > VBA, but that VARIANT which is VT in C++)
    > This VARIANT object has a data member for the value (this is an
    > anonymous C++ union) and a data member indicating the type of
    > information stored in the union. That is why I used the analogy with a
    > database record / MEMO field (and surely made very upset all
    > professional C++ programmers :)
    > This VARIANT object also has data member with pointer to IDispatchEx
    > interface extending the base IDispatch interface: that lets your object
    > to be a reference to something else or to be a member of some other
    > object.
    > It also has a data member with flag set by Garbage Collector. Once for
    > a while Garbage Collector comes, studies the object and if no in-scope
    > references found, it raises this flag ("that is a garbage to remove").
    >
    > There is a few other fields (like a pointer to IUnknown), but the above
    > members are the most essential for the core functionality.
    >
    > All this structure in application to the script engine is called
    > scavenger, and it is not to mix with a heap, because the value itself
    > is not here but only referenced to.
    >
    > (The mythological "native ECMAScript object with internal [[values]]"
    > is an allegoric decription of the scavenger in the way of how ECMA's
    > free-lancers saw it in 1999 on Netscape 4.x).
    >
    > >From this point forward your variable is ready to be whatever

    > programmer's unlimited fantasy :) will make it be at any moment: a
    > primitive value, an object reference, a function, an object member - it
    > will not catch the engine on cold.
    >
    > The byte-exact size of the structure depends on the current OS and on
    > the bit-base of the OS (16bit, 32bit, 64bit). You may look at C++ specs
    > for VARIANT to find out.
    >
    > If you are really interested in the "night life" of the JScript engine
    > and if you have some knowledge of C++ programming, search MSDN for
    > IDispatch and IDispatchEx methods. Then you can write an util to
    > connect to the engine to see scavengers appearing, GC roaming from
    > scavenger to scavenger, references changing, the garbage removed.
    >
    > P.S. JScript description above is not directly applicable to
    > JScript.NET
    > The latter is a rather different beast.
    >
    > P.P.S. From the optimization point of view it is tempting to create at
    > least short-living primitive values as just primitive values in hope to
    > the programmer's reasonnable behavior; and in case of type change
    > dereference the primitive and and to create a VARIANT with the same
    > name. A pure speculation from my side but maybe such mechanics is
    > implemented in some engines.


    You explanation is amazing.
    I almost gave up on this question.
    And you rescued me.

    Thank you very much.
    I'll study some more on the materials you recommended.

    Sam
     
    Sam Kong, Oct 14, 2006
    #4
  5. Sam Kong

    VK Guest

    > VK wrote:
    > search MSDN for IDispatch and IDispatchEx methods.


    Just noticed an ambiguosity here, better to say "IDispatch and
    IDispatchEx *and their* methods" - otherwise it is possible to read as
    if IDispatch and IDispatchEx are some methods while they are
    interfaces. For just a hell of it correction... :)

    > You explanation is amazing.
    > I almost gave up on this question.
    > And you rescued me.
    >
    > Thank you very much.
    > I'll study some more on the materials you recommended.


    You are welcome - and please share if you find something interesting.
    In the particular I did not get a clear reference on MSDN of how do
    they handle short-living scavengers with primitive values (say var i in
    for(var i=0;...) loop inside a function.

    Overall collecting such info is a pain in one place (my previous post
    summarized the info collected from a good dozen of sources on MSDN,
    MSDN forums and private blogs of IE developers). Overall no one
    producer is rushing to disclose all internal mechanics of their engine
    for the obvious security considerations. In this aspect JScript engine
    is the post open one; Gecko engine is the most closed one however funny
    it may sound. Of course Gecko's entire source is open, but where to
    look without a single hit? That is way too much of a challenge if you
    are not a real C++ professional - and I am not.
     
    VK, Oct 14, 2006
    #5
  6. In article <>, VK
    <> writes

    <snip>
    >It also has a data member with flag set by Garbage Collector. Once for
    >a while Garbage Collector comes, studies the object and if no in-scope
    >references found, it raises this flag ("that is a garbage to remove").


    VK has somehow switched from talking about the data structure that
    implements a property value to the data structure that implements an
    object.


    >There is a few other fields (like a pointer to IUnknown), but the above
    >members are the most essential for the core functionality.
    >
    >All this structure in application to the script engine is called
    >scavenger, and it is not to mix with a heap, because the value itself
    >is not here but only referenced to.
    >
    >(The mythological "native ECMAScript object with internal [[values]]"
    >is an allegoric decription of the scavenger in the way of how ECMA's
    >free-lancers saw it in 1999 on Netscape 4.x).

    <snip>

    For some reason VK won't admit that an object's data structure includes
    a field that points to the front of its prototype chain. Either that or
    he doesn't like it to be given a name, [[Prototype]], so we can talk
    about it even though we can't program it directly.


    >You may look at C++ specs
    >for VARIANT to find out.

    <snip>

    You won't find it in the C++ Standard. The next issue will have
    something based on boost::variant but its name will certainly not be all
    uppercase.


    John
    --
    John Harris
     
    John G Harris, Oct 15, 2006
    #6
  7. Sam Kong

    VK Guest

    > >It also has a data member with flag set by Garbage Collector. Once for
    > >a while Garbage Collector comes, studies the object and if no in-scope
    > >references found, it raises this flag ("that is a garbage to remove").


    > VK has somehow switched from talking about the data structure that
    > implements a property value to the data structure that implements an
    > object.


    I didn't switch because there is no "data structure that implements a
    property value" as such - unless we are talking about some abstract
    model, while the OP's question was about real implementations. There is
    one data structure then and special data fields in this structure
    defining what kind of structure is that and what higher level relations
    this data structure has/may have with other structures. You may take a
    closer look at the methods (listed in the order of the actual call
    sequence):

    IDispatchEx::GetDispID
    IDispatchEx::GetMemberProperties
    IDispatchEx::InvokeEx

    > For some reason VK won't admit that an object's data structure includes
    > a field that points to the front of its prototype chain. Either that or
    > he doesn't like it to be given a name, [[Prototype]], so we can talk
    > about it even though we can't program it directly.


    If we are talking about ECMA terms then I definitely don't like
    [[Class]] name in application to Object vs. Function as rather
    misleading. Even if the relevant field in Netscape's scavenger was
    called this way, ECMA could find some better abstraction for the public
    reading, say boolean [[MayCall]] or [[MayExecute]]. At the same time I
    have nothing against the name [[Prototype]], but there is one problem
    with it: if you take a look at the above-mentioned methods, you don't
    see any prototypes or prototype chain in there. This is what is was
    saying before: either you stay on the language level and talk avout
    what does this given language have - or you are going behind the scene
    to see how these higher level human abstractions are actually
    implemented. And you have to be very cautious in mixing both levels
    because you may easily get into the position of a man calculating
    electron orbits by Newton's formulas.
    On the level where you so insistently want go with your [[Prototype]]
    there are no prototypes and there is no inheritance at all: neither
    prototype-based nor class-based. There are objects connected in the
    most different ways to each other over interfaces. Just one step
    further (jumping over assembly) ant it will be some raw
    00000010 10000000 00000000 00000110...
    processor instructions and from this point it is not really important
    anymore what script is that and what other language is possibly running
    this script engine.

    At the same time I'd like to state publicly that I do believe in
    prototype as a vital property of javascript *language* objects; I do
    believe that javascript natively supports prototype-based inheritance;
    that I love prototype and I never tried to abuse it neither by words
    nor by disrespectful actions.
    :) :-|

    <http://www.microsoft.com/mind/1099/dynamicobject/dynamicobject.asp>
    can be also interesting

    > >You may look at C++ specs
    > >for VARIANT to find out.

    > <snip>


    > You won't find it in the C++ Standard. The next issue will have
    > something based on boost::variant but its name will certainly not be all
    > uppercase.


    Right, it's the Microsoft Automation stuff, so I should better say
    "look at Microsoft C++ and C# specs".
     
    VK, Oct 15, 2006
    #7
  8. Re: Questions about memory structure of value types and referencetypes

    VK wrote:

    Please attribute quoted text properly.

    [John G Harris wrote:]
    >> VK has somehow switched from talking about the data structure that
    >> implements a property value to the data structure that implements
    >> an object.

    >
    > I didn't switch because there is no "data structure that implements a
    > property value" as such - unless we are talking about some abstract
    > model, while the OP's question was about real implementations.


    So far, you have only mentioned details about JScript. Unless you have
    examined the implementation of every language (and I /know/ you
    haven't), you cannot eliminate possible approaches.

    [snip]

    > If we are talking about ECMA terms then I definitely don't like
    > [[Class]] name in application to Object vs. Function as rather
    > misleading.


    What? Are you just making up the meaning of things again? It's hard to tell.

    > Even if the relevant field in Netscape's scavenger was called this
    > way, ECMA could find some better abstraction for the public reading,
    > say boolean [[MayCall]] or [[MayExecute]].


    Why? That isn't what the [[Class]] property represents.

    > At the same time I have nothing against the name [[Prototype]], but
    > there is one problem with it: if you take a look at the
    > above-mentioned methods, you don't see any prototypes or prototype
    > chain in there.


    Whether that is true or not, it doesn't mean much. Again, one
    implementation is not representative of all implementations. Moreover,
    the prototype chain could be handled internally and wouldn't need to
    exposed directly. If the IDispatchEx interface is merely a COM mechanism
    for exposing the scripting engine to a host (it seems to be, but I don't
    know, nor do I really care), then why should that host be given direct
    access to the prototype chain?

    How do you propose that the Object.prototype.isPrototypeOf method
    asserts that an object is present within the prototype chain if there is
    no prototype chain? How about the instanceof operator? It calls the
    internal [[HasInstance]] method, which in turn examines the prototype chain.

    In case you need reminding (and you often do), the ECMAScript
    specification defines behaviour not implementation. No, there doesn't
    necessarily need to be a prototype chain, but an implementation must
    behave as though there were where that feature has significance. It
    seems rather perverse to me to store meta data about properties that
    signifies whether those properties are or aren't inherited, or whether a
    particular object inherits from another given object, rather than
    realising that inheritance.

    [snip]

    >> You won't find [VARIANT] in the C++ Standard. ...

    >
    > Right, it's the Microsoft Automation stuff, so I should better say
    > "look at Microsoft C++ and C# specs".


    Why? It's still not part of the language. A more sensible place to look
    would be the COM reference.

    Mike
     
    Michael Winter, Oct 16, 2006
    #8
  9. Sam Kong

    Sam Kong Guest

    Michael Winter wrote:
    > VK wrote:
    >
    > Please attribute quoted text properly.
    >
    > [John G Harris wrote:]
    > >> VK has somehow switched from talking about the data structure that
    > >> implements a property value to the data structure that implements
    > >> an object.

    > >
    > > I didn't switch because there is no "data structure that implements a
    > > property value" as such - unless we are talking about some abstract
    > > model, while the OP's question was about real implementations.

    >
    > So far, you have only mentioned details about JScript. Unless you have
    > examined the implementation of every language (and I /know/ you
    > haven't), you cannot eliminate possible approaches.
    >
    > [snip]
    >
    > > If we are talking about ECMA terms then I definitely don't like
    > > [[Class]] name in application to Object vs. Function as rather
    > > misleading.

    >
    > What? Are you just making up the meaning of things again? It's hard to tell.
    >
    > > Even if the relevant field in Netscape's scavenger was called this
    > > way, ECMA could find some better abstraction for the public reading,
    > > say boolean [[MayCall]] or [[MayExecute]].

    >
    > Why? That isn't what the [[Class]] property represents.
    >
    > > At the same time I have nothing against the name [[Prototype]], but
    > > there is one problem with it: if you take a look at the
    > > above-mentioned methods, you don't see any prototypes or prototype
    > > chain in there.

    >
    > Whether that is true or not, it doesn't mean much. Again, one
    > implementation is not representative of all implementations. Moreover,
    > the prototype chain could be handled internally and wouldn't need to
    > exposed directly. If the IDispatchEx interface is merely a COM mechanism
    > for exposing the scripting engine to a host (it seems to be, but I don't
    > know, nor do I really care), then why should that host be given direct
    > access to the prototype chain?
    >
    > How do you propose that the Object.prototype.isPrototypeOf method
    > asserts that an object is present within the prototype chain if there is
    > no prototype chain? How about the instanceof operator? It calls the
    > internal [[HasInstance]] method, which in turn examines the prototype chain.
    >
    > In case you need reminding (and you often do), the ECMAScript
    > specification defines behaviour not implementation. No, there doesn't
    > necessarily need to be a prototype chain, but an implementation must
    > behave as though there were where that feature has significance. It
    > seems rather perverse to me to store meta data about properties that
    > signifies whether those properties are or aren't inherited, or whether a
    > particular object inherits from another given object, rather than
    > realising that inheritance.
    >
    > [snip]
    >
    > >> You won't find [VARIANT] in the C++ Standard. ...

    > >
    > > Right, it's the Microsoft Automation stuff, so I should better say
    > > "look at Microsoft C++ and C# specs".

    >
    > Why? It's still not part of the language. A more sensible place to look
    > would be the COM reference.
    >
    > Mike


    Do you personally have a problem with VK?
    I would appreciate if you were not that aggressive in this public
    place.
    (If I misunderstood, I apologize.)

    Thank you for your complementary explanation.

    Sam
     
    Sam Kong, Oct 16, 2006
    #9
  10. In article <>, Sam
    Kong <> writes

    <snip>
    >Do you personally have a problem with VK?


    Many of us have a problem with VK. He gives out misleading information
    far too often.


    >I would appreciate if you were not that aggressive in this public
    >place.

    <snip>

    I'm afraid you are going to be disappointed. And anyway, 'that' was not
    at all aggressive, only firmly stated.

    John
    --
    John Harris
     
    John G Harris, Oct 16, 2006
    #10
  11. In article <>, VK
    <> writes
    >> >It also has a data member with flag set by Garbage Collector. Once for
    >> >a while Garbage Collector comes, studies the object and if no in-scope
    >> >references found, it raises this flag ("that is a garbage to remove").

    >
    >> VK has somehow switched from talking about the data structure that
    >> implements a property value to the data structure that implements an
    >> object.

    >
    >I didn't switch because there is no "data structure that implements a
    >property value" as such - unless we are talking about some abstract
    >model, while the OP's question was about real implementations. There is
    >one data structure then and special data fields in this structure
    >defining what kind of structure is that and what higher level relations
    >this data structure has/may have with other structures.


    You're saying there's one big data structure with a typed union able to
    hold one of
    a) A value (a property value) which is one of several different types,
    or
    b) An object, possibly owning hundreds of property values.

    I suppose it's possible; the code was written by Microsoft people after
    all. But using OLE Automation to get at a property value seems crazy.


    >You may take a
    >closer look at the methods (listed in the order of the actual call
    >sequence):
    >
    >IDispatchEx::GetDispID
    >IDispatchEx::GetMemberProperties
    >IDispatchEx::InvokeEx
    >
    >> For some reason VK won't admit that an object's data structure includes
    >> a field that points to the front of its prototype chain. Either that or
    >> he doesn't like it to be given a name, [[Prototype]], so we can talk
    >> about it even though we can't program it directly.

    >
    >If we are talking about ECMA terms then I definitely don't like
    >[[Class]] name in application to Object vs. Function as rather
    >misleading. Even if the relevant field in Netscape's scavenger was
    >called this way, ECMA could find some better abstraction for the public
    >reading, say boolean [[MayCall]] or [[MayExecute]].



    >At the same time I
    >have nothing against the name [[Prototype]], but there is one problem
    >with it: if you take a look at the above-mentioned methods, you don't
    >see any prototypes or prototype chain in there.

    <snip>

    How do you explain what happens when you do
    x.toString()
    What words would you use to say that the javascript engine must look for
    something named toString ? How would you say it must go from object to
    object looking for it ? How would you say which objects it must look at?

    Note that objects *are* visible at the language level.

    John
    --
    John Harris
     
    John G Harris, Oct 16, 2006
    #11
  12. Sam Kong

    VK Guest

    John G Harris wrote:
    > You're saying there's one big data structure with a typed union able to
    > hold one of
    > a) A value (a property value) which is one of several different types,
    > or
    > b) An object, possibly owning hundreds of property values.


    I did not say that. I said that behind the scene there are not
    properties and objects, but only objects - not javascript objects but
    COM objects - with hierarchy of relations (found by plain-vanilla
    iterations).
    To put it in the most plain words, if we have ObjectOne with 100
    properties where say 99 hold primitive values and one is ObjectTwo with
    10 own properties then the math is:
    1 + 100 + 10 = 111 separate scavengers.

    > How do you explain what happens when you do
    > x.toString()


    Happens where? In the language or in the engine?

    For the first you know the answer: it is as spelled in language
    references. I also found very interesting for myself this article:
    "The JScript Type System, Part Two: Prototypes and constructors"
    <http://blogs.gotdotnet.com/ericlippert/archive/2003/11/06/53352.aspx>

    For the engine side you may read:

    "Wherefore IDispatchEx?"
    <http://blogs.gotdotnet.com/ericlippert/archive/2004/10/07/239289.aspx>

    "How Do Script Engines Implement Object Identity?"
    <http://blogs.gotdotnet.com/ericlippert/archive/2005/04/26/412199.aspx>

    "The layout of a COM object"
    <http://blogs.msdn.com/oldnewthing/archive/2004/02/05/68017.aspx>

    "How do the script Garbage Collectors work?"
    <http://blogs.msdn.com/ericlippert/archive/2003/09/17/53038.aspx>

    Overall the most tricky questions should be posed to Eric Lippert and
    not to VK: because Eric Lippert is the one who wrote the original
    JScript engine and maintained it for many years:
    <http://blogs.gotdotnet.com/ericlippert/contact.aspx>
     
    VK, Oct 16, 2006
    #12
  13. In article <>, VK
    <> writes
    >
    >John G Harris wrote:
    >> You're saying there's one big data structure with a typed union able to
    >> hold one of
    >> a) A value (a property value) which is one of several different types,
    >> or
    >> b) An object, possibly owning hundreds of property values.

    >
    >I did not say that. I said that behind the scene there are not
    >properties and objects, but only objects - not javascript objects but
    >COM objects - with hierarchy of relations (found by plain-vanilla
    >iterations).
    >To put it in the most plain words, if we have ObjectOne with 100
    >properties where say 99 hold primitive values and one is ObjectTwo with
    >10 own properties then the math is:
    >1 + 100 + 10 = 111 separate scavengers.


    Do all these C++? objects belong to the same class?

    If they do then each class instance holds a data structure able to hold
    either a javascript object or a javascript property, and you did say
    that.

    If they don't then there is a class with each instance holding a
    javascript object and another class with each instance holding a
    property, and you did switch subjects.

    And the arithmetic is 1 + 100 + 1 + 10 = 112.


    >> How do you explain what happens when you do
    >> x.toString()

    >
    >Happens where? In the language or in the engine?


    In the program when it's executing of course. What else?


    >For the first you know the answer: it is as spelled in language
    >references.


    So you admit that there is a language reference. It's called ECMA 262
    for the core language features.


    <snip>

    John
    --
    John Harris
     
    John G Harris, Oct 17, 2006
    #13
    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. Sathyaish
    Replies:
    2
    Views:
    601
    Sathyaish
    May 22, 2005
  2. Migrators

    memory structure in C and value of EOF

    Migrators, May 16, 2004, in forum: C Programming
    Replies:
    5
    Views:
    4,924
    Gordon Burditt
    May 16, 2004
  3. Excluded_Middle

    Pointers to structure and array of structure.

    Excluded_Middle, Oct 24, 2004, in forum: C Programming
    Replies:
    4
    Views:
    774
    Martin Ambuhl
    Oct 26, 2004
  4. Replies:
    2
    Views:
    619
  5. venkatagmail
    Replies:
    11
    Views:
    698
    James Kanze
    Oct 3, 2007
Loading...

Share This Page