none
Superodinate term for reference and object

    Question

  • Hi,

    maybe I forgot it, but not everything that is data and occupies memory is an object because there are also references. So, what is the superordinated term for references and objects? I'd like to call it "value", but that could easily be mixed up with "value" in "value types". I'd like to be able to say that there are two kinds of ______: references and objects. How could I replace the "_____"? I know, it's a pretty basic question... :-)


    Armin

    Saturday, September 14, 2013 9:44 PM

Answers

  • I think "piece of data" is the only answer. (in my language the ambiguous term "Datum" because it also means date; one reason why I don't like it that much).

    Armin

    • Marked as answer by Armin Zingler Monday, September 16, 2013 11:17 AM
    Sunday, September 15, 2013 2:51 AM

All replies

  • I think just "data" is ok. (somehow this is already contained in the first sentence of my question...)

    Would you agree with "Every piece of data is of one of two kinds: object or reference"?

    EDIT: But "piece of data" is not very handy to refer to one "thing".


    Armin


    Saturday, September 14, 2013 9:57 PM
  • ...but not everything that is data and occupies memory is an object because there are also references.

    But a class itself is a reference type.

    ...or did I miss your point entirely? ;-)


    Please call me Frank :)

    Saturday, September 14, 2013 11:03 PM
  • Yes, a class type itself is a reference type. But a class doesn't occupy memory at run-time whereas a reference does. I'm referring to a reference (32 or 64 bits).

    My point is: If you look at the memory content at run-time, there are only two categories of data: objects and references. Of course, objects can be composed of both of them again, but I'm referring to the indivisible types like Integer, Double, DateTime (all three are objects), and also references (which are not objects). So, can we only say objects and references are two catgeories of data, or is there a more precise term?

    Armin

    Saturday, September 14, 2013 11:24 PM
  • Yes, a class type itself is a reference type. But a class doesn't occupy memory at run-time whereas a reference does. I'm referring to a reference (32 or 64 bits).

    My point is: If you look at the memory content at run-time, there are only two categories of data: objects and references. Of course, objects can be composed of both of them again, but I'm referring to the indivisible types like Integer, Double, DateTime (all three are objects), and also references (which are not objects). So, can we only say objects and references are two catgeories of data, or is there a more precise term?

    Armin

    Armin - you're in a league that I can't imagine being in (not lionizing here, just stating that), so if you don't know, I sure the heck don't!

    Anyway ...

    When you instantiate a class, that instance doesn't take up memory? I'm sure that I've misunderstood?

    I'm sure that I'm not - and I suspect that your question is more rhetorical than not, but keep it on here -- there are some super bright folks here! I'm looking forward to watching the conversation develop. :)


    Please call me Frank :)

    Saturday, September 14, 2013 11:33 PM
  • Frank, thanks for trying to understand my language. :-) Yes, that instance of a class occupies memory. But the reference to it that you, for example, store on the stack, also occupies memory. So we have two kinds of...um....data: objects and references.

    "data"
      |
      +-- objects
      +-- references



    Armin

    Saturday, September 14, 2013 11:53 PM
  • Frank, thanks for trying to understand my language. :-) Yes, that instance of a class occupies memory. But the reference to it that you, for example, store on the stack, also occupies memory. So we have two kinds of...um....data: objects and references.

    "data"
      |
      +-- objects
      +-- references



    Armin

    Hmm ... I think maybe I am starting to understand.

    Interesting conjecture. I'll defer to others on this, but I (somewhat) understand what you mean.

    Something to think about for sure!


    Please call me Frank :)

    Saturday, September 14, 2013 11:56 PM
  • Or, in other words: (also a different attempt to explain)

    If you want to find a more abstract representation of this block of memory

    Integer object
    Boolean object
    DateTime object
    Reference
    Single object

    would it be

    piece of data
    piece of data
    piece of data
    piece of data
    piece of data

    And i'm trying to find a better word for "piece of data".

    EDIT: yes, this is a theoretical question, but it came to my mind while writing a programming introduction.


    Armin


    Sunday, September 15, 2013 12:08 AM
  • If you want to find a more abstract representation of this block of memory

    Integer object
    Boolean object
    DateTime object
    Reference
    Single object

    would it be

    piece of data
    piece of data
    piece of data
    piece of data
    piece of data

    And i'm trying to find a better word for "piece of data".

    Actually this skipped one level of abstraction. These should be abstracted:

    object
    object
    object
    reference
    object


    Armin


    Sunday, September 15, 2013 12:15 AM
  • But the reference to it that you, for example, store on the stack, also occupies memory. So we have two kinds of...um....data: objects and references.

    That perhaps hints at the problem. 

    I don't store anything on the stack.  The runtime does that.  I just manipulate data, and for most purposes I am not concerned whether the data is a value or a reference or where it is stored.  The compiler and the runtime needs to know that, because it needs to know what has to be dereferenced, and how.  But at the code level the dereferencing is mostly transparent.

    So I think there is no right way to say - "there are two kinds of ______: references and objects" because that distinction is not two kinds.  

    I would say 'Data can be used in two different ways - directly as a value, or indirectly as a reference to other data" (note the allowance for recursion).   The distinction is two usages.  What is data in one circumstance (a number is accessed from the class data definition table and pushed onto the stack) is a reference in another (the value at the top of the stack is popped and used as an offset into the data segment of the class instance).

    It is the responsibility of the user of the data to know whether a number that it is manipulating is to be used as a value or as a reference - there is nothing inherent in the data that defines it as a value or a reference.  But perhaps that concept - the 32-bit binary number that is the basic element of information within an application - is what you were trying to name as the conflated superordinated term. 

    Sunday, September 15, 2013 12:48 AM
  • I am not sure what you mean by "reference".

    There are two data types: Value Types and Reference Types.  A  class is not an object, an instance of a class is a object.  A class can be a value type or reference type. Both value types and reference type inherit the object class.  Value types are placed on the stack because the compiler knows exactly how much memory a value type uses.  A reference type is placed on the Managed Heap and a pointer (unsigned integer) is created on the stack to refer to the reference type. A value type can be "boxed" and placed on the managed heap. A boxed value type must be unboxed when the code refers to it. When a pointer to a reference type goes out of scope, the reference type can be cleaned from the managed heap by the garbage collector, if it happens to execute.

    A structure is a value type, but can contain a reference type.  The pointer to the reference type is included in the structure on the stack.

    Maybe by reference you mean pointer or handle.

    two kinds of Data created in memory: pointers and objects. Objects can be a value type or a reference type. Pointers are used to identify the location in memory of an object.

    See IntPtr in the MSDN documentation.


    The difference between genius and stupidity is that genius has its limits.



    • Edited by Topdog224 Sunday, September 15, 2013 2:21 AM
    Sunday, September 15, 2013 1:54 AM
    • "I don't store anything on the stack.  The runtime does that."

    Ok, the CPU does it, or the memory controller, but I write the code, that's why I said that I store it on the stack. I think this is common language because we are thinking ahead while writing the code, putting ourselves in the position of the CPU. Of course, I don't say everyone has to care about where local variables are stored, but I do. However, this is not important.

    Referring to what you wrote further: It's ok if you don't want to make the distinction, but I see a clear difference between these two kinds of data. I agree that this has influence on the usage and syntax, but that's not what I'm focussing on. Of course you can also say it's all ones and zeroes, but the layer I'm talking about is what we programmers actively influence. It's the data we're working with, and there's no doubt that that data can be categorized into these two kinds. The question is more if you want to do it and which point of view you want to take. 

    We always say that all "data" has a certain data type (Integer, Form, etc.). However, this is only true for objects, not for references. If in "Dim f as Form", the Form object is of type Form, of which type is the reference to the Form? If you say "the same", then the reference would have to have the same size as the Form object.

    This is about different points of view. Not in the sense of different opinions but of different locations from where to look at the same thing. For example, you can consider a VB project either as a collection of files, or you can consider it as collection of declarations. Both exist, and there's no contradiction.

    So, imagine you're examining memory, one piece of data after the other. Someone asks you "what is this?". You can say: an object of type Integer. Next one: This is an object of type Date. Next one: This is a reference. A reference is not an object.
    I know the data type is not readable from looking at 0s and 1s, but this is clear. The point is: by
     explaining what you have there, it clearly turns out that there are two kinds of data: objects and references. What we don't seem to have is an abstract term for this, or it's just "data". I can live with that well, though I'm surprised there is no headline for the two sub categories. When talking about data, this is even the main distinction to be made. Syntax or usage comes later.


    Armin

    Sunday, September 15, 2013 2:13 AM

    • I am not sure what you mean by "reference".

    I mean a piece of data pointing to an object of a reference type (including boxed value types). A managed pointer.

    • There are two data types: Value Types and Reference Types. 

    Value types and reference types are not data types. Maybe they are two kinds of data types. (and ValueType is additionally a base type.)

    •  A class can be a value type or reference type.

    Isn't a class always a reference type?

    • Value types are placed on the stack because the compiler knows exactly how much memory a value type uses.

    No, only local variables of a value type are placed on the stack. Most objects are of class types stored on the heap, and they are made of fields of value types.

    • a pointer (unsigned integer) is created on the stack to refer to the reference type. 

    A (managed) pointer (aka reference) is not necessarily on the stack.

    •  A value type can be "boxed" and placed on the managed heap. A boxed value type must be unboxed when the code refers to it. 

    Right.

    Anyway, this is clear so far. However it's not what I mean.

    (Sorry for the font problems. This editor did it for me....)


    Armin

    Sunday, September 15, 2013 2:28 AM

    • I am not sure what you mean by "reference".

    I mean a piece of data pointing to an object of a reference type (including boxed value types). A managed pointer.

    • There are two data types: Value Types and Reference Types. 

    Value types and reference types are not data types. Maybe they are two kinds of data types. (and ValueType is additionally a base type.)

    •  A class can be a value type or reference type.

    Isn't a class always a reference type?

    • Value types are placed on the stack because the compiler knows exactly how much memory a value type uses.

    No, only local variables of a value type are placed on the stack. Most objects are of class types stored on the heap, and they are made of fields of value types.

    • a pointer (unsigned integer) is created on the stack to refer to the reference type. 

    A (managed) pointer (aka reference) is not necessarily on the stack.

    •  A value type can be "boxed" and placed on the managed heap. A boxed value type must be unboxed when the code refers to it. 

    Right.

    Anyway, this is clear so far. However it's not what I mean.

    (Sorry for the font problems. This editor did it for me....)


    Armin

    Value types are a structure, which I consider to be a special non-inheritable class. A structure can have a constructor and properties and methods. From MSDN for Int32: Public Structure Int32 which has methods such as TryParse. However I should have distinguished between classes and structures.  I probably the only one who considers a structure a special class.

    If you look at the IL code, the pointer to a reference type created on the managed heap is placed on the stack when an instance of the reference is created.  Now if that instance is added to a collection such as List(Of T), then the pointer is copied from the stack to the managed heap.


    The difference between genius and stupidity is that genius has its limits.


    • Edited by Topdog224 Sunday, September 15, 2013 3:40 AM
    Sunday, September 15, 2013 2:44 AM
  • I think "piece of data" is the only answer. (in my language the ambiguous term "Datum" because it also means date; one reason why I don't like it that much).

    Armin

    • Marked as answer by Armin Zingler Monday, September 16, 2013 11:17 AM
    Sunday, September 15, 2013 2:51 AM
  • So, imagine you're examining memory, one piece of data after the other. Someone asks you "what is this?". You can say: an object of type Integer. Next one: This is an object of type Date. Next one: This is a reference. A reference is not an object.
    I know the data type is not readable from looking at 0s and 1s, but this is clear. The point is: by
     explaining what you have there, it clearly turns out that there are two kinds of data: objects and references. What we don't seem to have is an abstract term for this, or it's just "data". I can live with that well, though I'm surprised there is no headline for the two sub categories. When talking about data, this is even the main distinction to be made. Syntax or usage comes later.

    I don't say that.   I say that variables have a type, and that the variable is not the data - the variable is the device used by the compiler to allow the coder to refer to their data.

    The main reason for this viewpoint is that the same data can be referred to as (for instance) an Object, a Form, or Form1, depending on the variable used to refer to it.  Of course, object instances have a Type property and reference to the object using a variable of that Type provides certain guarantees. But that does not mean the object cannot be referred to as different types.  Without separating variables from their objects and pinning the Type to the variable it becomes very difficult to explain what CType actually does.

    [This viewpoint pushes the value/reference distinction to a lower level of significance, which creates problems of its own.  But I find those problems easier to deal with if I start from the concept of variables as references to data first, and make the value/reference distinction later.]

    So from this viewpoint, all variables are references to data.  That is true at compile time, but of course at run time (when I examine memory and pose the question you posed above) the variables don't exist - only the data exists at run time.  So from my viewpoint I can only consider some 'type' for runtime data in terms of how it actually gets used - there is nothing inherent in the data that defines it as a value or a reference, and the two categories are completely indistinguishable without a full context.  That's why I recast your query into a usage question instead of a kind question.

    But let me throw this into the discussion:  If I create a delegate have I created an object or a reference?  Or both?

    Sunday, September 15, 2013 3:41 AM
  • Off topic:

    "So from this viewpoint, all variables are references to data.  That is true at compile time, but of course at run time (when I examine memory and pose the question you posed above) the variables don't exist - only the data exists at run time."

    If all the garbage collector saw was the run time data, it could not perform it's job.  The GC could not identify an object as live or dead.  That is the reason IL code and the JIT compiler exist.  The GC's stack crawler and handle list uses the IL code to identify the type and scope of memory contents.  

     

    The garbage collector uses the following information to determine whether objects are live:

    • Stack roots. Stack variables provided by the just-in-time (JIT) compiler and stack walker.

    • Garbage collection handles. Handles that point to managed objects and that can be allocated by user code or by the common language runtime.

    • Static data. Static objects in application domains that could be referencing other objects. Each application domain keeps track of its static objects.

     

    The difference between genius and stupidity is that genius has its limits.


    • Edited by Topdog224 Sunday, September 15, 2013 4:24 AM
    Sunday, September 15, 2013 4:05 AM
  • (in advance, sorry again for the formatting. small font appears suddenly during normal editing)

    • I don't say that. 

    "You" means everyone. Let me rephrase: Someone asks me "what is this?". I say: an object (of type Integer). And I (or you, or we, or anyone) can say for every piece of data what it is. The answer is in any case that it is either an object or a reference.

    • the variable is not the data 

    The terms variables, inheritance or delegates do not play a role in this context. It's making it unnecessarily complicated. How the language handles this comes later. Before, you have to know what you are dealing with.

    Just to imagine: Forget everything you know. Then you learn something about data: What a simple data type (Int32 etc) is, what a composed data type is and that these values are called objects. You learn that you can additionally have references to objects. Now you know that there are two kinds of data: objects and references. This is a fact not invented by me. A teacher should be able to put this in a schema that says: "pieces of data" are either objects or references. 

    With this basic knowledge you are now able to categorize "piece of data" or "those things in memory". Obviously not a catchy term, hence this thread.

    We have the superordinated term "vehicle" for cars, bicycles, trucks, etc. So I have the possibility to ask: What kind of vehicle is this, and that, and this one....?  The possible answers are car, bike or truck.

    • That's why I recast your query into a usage question instead of a kind question.

    You can do this but that's not the question I had. :-) 

    But as written already, I can live with the fact that there is no other term. 


    Armin

    Sunday, September 15, 2013 8:26 AM
  • "[...]the two categories are completely indistinguishable without a full context."

    It's an intellectual distinction, not a distinction made by looking at bit patterns.


    Armin

    Sunday, September 15, 2013 8:29 AM
  •   "Apparatus" ?  ?


    Leon C Stanley - - A dinky di VBer - - Code is like fresh baked bread - it goes stale after a while - - so why try to immortalize it ? and turn it into a Class? ^^ :-)

    Sunday, September 15, 2013 10:09 AM
  •   "Apparatus" ?  ?

    I will take that, thanks! :-)

    Armin

    Sunday, September 15, 2013 3:28 PM
  • I don't think that "data" fits, because I would think of the data as the values, whether they are directly or indirectly accessed.

    And I'm not sure that references and objects are coordinate, seeing as a reference ultimately points to an object.

    Maybe the remarks section of ValueType Class ("Data types are separated into value types and reference types...") will help to make it <strike>more confusing</strike> clearer.

    --
    Andrew


    • Edited by Andrew Morton Sunday, September 15, 2013 4:08 PM markup
    Sunday, September 15, 2013 4:06 PM
  • Hi,

    maybe I forgot it, but not everything that is data and occupies memory is an object because there are also references. So, what is the superordinated term for references and objects? I'd like to call it "value", but that could easily be mixed up with "value" in "value types". I'd like to be able to say that there are two kinds of ______: references and objects. How could I replace the "_____"? I know, it's a pretty basic question... :-)


    Armin

    Wow this thread got a little busy... I have not read it all but am guessing you still need an answer (nothing marked yet).

    I believe the word you are looking for is simply Type (or Data Type).

    "There are two kinds of Types in .Net: Reference Types and Value Types."

    You can't separate out the word "Object" from anything else because everything is an object.  But all objects derive from a specific Type definition and that Type Definition will define an object as being either a value or reference type.

    Now, if you only want to speak in terms of allocated objects and not in terms of type definitions, then you might use the term "Variable".  After all, no matter what the type definition, the object instance will always be a variable.

    -EDIT-

    I suppose if you wanted to dive deeper in your explanation then you could talk briefly about what a pointer is and how .Net uses them... then you could differentiate between an object and a pointer to an object.  But that's probably beyond the scope of a simple explanation of value/reference types in .Net.


    Reed Kimble - "When you do things right, people won't be sure you've done anything at all"


    Sunday, September 15, 2013 4:50 PM
    Moderator
  • Reed,

    I didn't expect this, too. I thought a single word is the answer. :-)  Instead I still have to explain a question that is very basic and simple. The only problem seems to be that nobody seems to have thought about it like me. Maybe because it's too basic that all we programmers do is just "pieces of data" pushing around.

    "Type" is not the answer because memory does not contain a sequence of types. It contains a sequence of ____ . No, not only a sequence of objects because a reference is not an object. Inheritance doesn't matter at this level.

    I think we can discuss long about the term "variable". Does a variable only exist as a name in source code or also as a variable (aka changable) value in memory at run-time? I'd vote for the latter. However, there are also constants (at run-time in memory). They are also "pieces of data", yet they are no variables.

    My favorite term would be just "values". I could happily say that memory contains values, and there are two kinds of values: objects and references.
    There is just one problem: There's the term "value types". I could not justify telling someone that a reference is a value, and that reference references an object of a reference type - which is not a value type. Too confusing. That's why "values" doesn't work.

    "After all, no matter what the type definition, the object instance will always be a variable." Well, not if it's a reference type. Then the variable is a reference, not an object.

    So, I've accepted that it's just data. Not bad, considering "data processing", etc.... Though, I vote for inventing a better singular for "data". ;-)

    EDIT:

    "You can't separate out the word "Object" from anything else because everything is an object." No, a reference is not an object.

    Regarding your edit: Not so important how a managed pointer works, but you now see that a reference is (by itself) not an object. In other words, why dig deeper in the internals as it is true without?


    Armin

    Sunday, September 15, 2013 5:20 PM
  • Here how I believe that all this is structured in memory :

    Quickly ...


    The Heap:
        Is  managed by the GC

    The Stack:
        Is  managed by the CLR
    ------------------------------

    An object reference is a pointer to an "Object Instance Table"
       this table contains:
               - "Syncblt" : It is an index 
               - "Type Handle" : it is a pointer to the "Method table"
               - The list of the Instance fields ( those instance fields are object references and therefore points to other Object Instance Tables 
    This Object Instance Table is in the GC heap

    ------------------------------

    The method tables are created in the stack 

    (when we say that a class is loaded, in fact, what was done is that table was build in memory)

    The first 12 fields of the table contains info relative to the GC, interface, delegate, ... etc

    Starting at the 13th fields are the method slots
       The first method slot contains an integer that is the number of methods in the type

       Then all other method slots contains a pointer to a "Method Descriptor table"
       There is one slot for each method of the type

    After the method slots, comes the Static Fields slots
       In those slots,
          If the data can fit on the 4 bytes slot, (As an integer, or a byte,...) it is written there
          If it dont fits, and the data is a value, a pointer to a location in the stack is entered in the slot
          If the data is not a value, (String, array) then in the slot is a pointer to a handle table
             (this handle table will hold some pointer to the data, but here the data will be in the GC Heap.(therefore, even static, a string and an array does have the data in the heap.This is nessessary for the management of an immutable object,.. even being Static)). It can be good here to say that if two instances of a string are created by the application and that those two strings have the same sequence of characteres, both string references will point to the same entry in the Handle table. Therefore, two identical string are the same object, Even if they were created by thow different object.

    After, in the method table comes the interfaces maps (8 bytes each). Here I will not go into how this works, just tell the purpose if these maps: When the CLR build a class, it scan the base classes, and the interfaces and just build a single Method table (Just one big type that contains all the fields, methods, etc.. ) When you cast a type to an interfaceor a base class, you feel like working with another object that is a subset of the type, but in fact you are not. The CLR just uses the inteface maps to decide which methods and fields are accessible in the Method Table

    Once build, the method table will never be unloaded until the end of the application
    ----------------------------
    Finally, just a few words about the Method descriptor tables:

       the Method descriptors when first created (at the same time that the method table is created.. ie: when the class is loaded), those tables contains pointers to the metadata that is needed to Jit the methods. Once jitted, the  Method descriptors tables contains pointers to the jitted methods


    ---------------------------



    • Edited by Crazypennie Monday, September 16, 2013 1:25 AM 123456
    Monday, September 16, 2013 12:02 AM
  • Only to close this thread, I marked it as the answer. Thanks for the discussion (though I keep the thread type as question).

    Armin

    Monday, September 16, 2013 11:17 AM