Hey, thanks for the reply. So what you're saying is that the implementation of 'object type values' being just reference values (pointers) to the memory location containing the object is an assumption rather than a fact? If that's the case, what is the actual implementation? This would be a huge revelation as most educational material online explain the implementation this way.
I'm trying really hard to understand your high level explanation of the implementation but I'm honestly confused because of how high level it is and the new terminology used. For example, you say "when I pass you my 'object type value' by value", that doesn't equate to some code that I can visualize, which forces me to infer that you mean when you assign your 'object type value' to a new variable, but my inference might be wrong. Then you say, "the 'object' is in the relationships". I've never heard of this relationship term used in Javascript before, so I have no idea what that sentence means. Please correct me if I'm wrong and if relationships is an actual term used in the implementation model instead of an abstract concept.
It could just be me though, since I understand explanations much easier from a low level rather than abstract explanations. Ultimately, I think I already understand 'how it works' at a high level and it seems to be the same as what you're explaining (regardless of whether we're using the term relationship or reference). However, I'm inclined to understand how things work under the hood (coming from a math and physics background), which why these high level explanations don't work well with me.
The value of the object is its identity, which enables us to access the object's properties.
Sharing this identity allows others to access the same properties.
So we don't need to talk about pointers or references -- we just need the object value and some way to use that to access the object's properties.
There's nothing special about numbers for object values in the example, it might as well have been strings, or dates, or anything that can provide an identity.
As for "under the hood", there isn't any -- unless you're assuming a particular implementation, in which case you're no-longer reasoning about the language, but some particular implementation of it.
If you come from a math background it should be natural to understand things in terms of relationships, rather than mechanics.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey, thanks for the reply. So what you're saying is that the implementation of 'object type values' being just reference values (pointers) to the memory location containing the object is an assumption rather than a fact? If that's the case, what is the actual implementation? This would be a huge revelation as most educational material online explain the implementation this way.
I'm trying really hard to understand your high level explanation of the implementation but I'm honestly confused because of how high level it is and the new terminology used. For example, you say "when I pass you my 'object type value' by value", that doesn't equate to some code that I can visualize, which forces me to infer that you mean when you assign your 'object type value' to a new variable, but my inference might be wrong. Then you say, "the 'object' is in the relationships". I've never heard of this relationship term used in Javascript before, so I have no idea what that sentence means. Please correct me if I'm wrong and if relationships is an actual term used in the implementation model instead of an abstract concept.
It could just be me though, since I understand explanations much easier from a low level rather than abstract explanations. Ultimately, I think I already understand 'how it works' at a high level and it seems to be the same as what you're explaining (regardless of whether we're using the term relationship or reference). However, I'm inclined to understand how things work under the hood (coming from a math and physics background), which why these high level explanations don't work well with me.
Let us consider a simple program.
Now imagine an implementation of Javascript in Javascript, where objects are represented as numbers, and we have Get and Set methods.
We might represent the above like so.
The value of the object is its identity, which enables us to access the object's properties.
Sharing this identity allows others to access the same properties.
So we don't need to talk about pointers or references -- we just need the object value and some way to use that to access the object's properties.
There's nothing special about numbers for object values in the example, it might as well have been strings, or dates, or anything that can provide an identity.
As for "under the hood", there isn't any -- unless you're assuming a particular implementation, in which case you're no-longer reasoning about the language, but some particular implementation of it.
If you come from a math background it should be natural to understand things in terms of relationships, rather than mechanics.