Data type questions

In the javascript review excersize, I noticed that they put objects and symbols as data types. This may seem obvious to some of you, but what are symbols and objects? I asked some questions about objects before, but I still don’t have a concrete idea of what it is. Could anyone explain what a object is, and why it can be classified as a data type?

1 Like

I found this Medium blogpost to be very informative! Maybe it will help you too :smiley:

You could check out the Objects lesson in the Learn Javascript course on Codecademy if you want to get an in-depth work through of the basics. Javascript is an object-oriented programming language( more specifically a prototype-based, object-oriented language). Meaning objects are quite important/prevalent in Javascript. I think the reason objects are considered data is because of what they inherently are, but mostly because of how Javascript deals with them.

To put it simply, “objects are collections of related data”. An object in programming is exactly what it sounds like. A thing. they are used to model real world things into our code, which helps us make sense of how our code interacts with data. Just like real world objects, programming objects have properties that define something about that object, and they also have methods which allow the object to do certain things. For example, a car has a property(that it is the colour blue) and also is able to do things(like turn on the blinkers). In your code, you could have an object that models a person and has a property( a name), and a method(that logs to the console “Hello, I am an object”). Of course, objects can have any number of properties and methods.

The reason objects are considered data is that objects are passed by reference. This means when you create an object using an object literal and assign it to a variable, what the variable saves isn’t really the object, but rather a little chunk of data that tells it where to find the object within the computer’s memory. So the object is known mostly by a little chunk of data that references where to find the actual object. This is why you can treat objects like data. And note also that since the properties of objects are data, a ‘property’ of an object can in fact be another object, which is called a nested object.

Unfortunately, I don’t know anything about symbols except that they are a primitive data type, and something about all symbols being unique.

So an object is like a function, except that it has properties. That is my interpretation of what you wrote. Also, what exactly is the properties that you are talking about? I feel like you are getting too realistic, data can’t have colors, and functions have names too. Also what is the little chunk of data that references the object? Is that like a variable name that you can call or is there some sort of key word?

Quick turn around… Functions are objects and they, too have properties. this, arguments, return, prototype, constructor, and so on.

An object is an execution context. Either they are doing the execution or they are having something executed on them.

function identity (x) {
    return x;

The constructor of this object is [Function: Function] and its prototype is [Function]. The return value is the parameter, unchanged. x is an object of any type.

[Function: identity]
{ identity: [Function: identity] }

As mtf mentioned, you’re on the right track there, except that in fact it is functions that are objects. Perhaps I was too abstract with my explanation, but your confusion about properties is understandable. As you stated, functions have names too, but it useful to specify that that is known as an identifier. An identifier allows a programmer to identify objects, and this identifier is what you use when coding to refer to an object(which can be a function).
Say you were making a game. The players start the game by creating a character. In your code, you might have objects that represent the players. They may have identifiers like Player 1 and Player 2, and each object would have properties that are assigned as the players make their characters. They might give their character a name, height, hair colour and so on. These would all be properties that the object is assigned anew each time the game is played. However you will always refer to the objects by those identifiers in your code. The ‘little chunk of data’ I talked about in the earlier post is something you don’t interact with directly. As in the example above the programmer refers to objects by the identifier. However it is useful to know what’s going on behind the scenes, because things like pass-by-reference can cause shenanigans if you aren’t careful.

Ok, lets go back to basics.
In JavaScript, what is an Object? It is simply a collection of key, value pairs, we can see this when we make an object:

const example = {
    "key1": "value1", // a pair of a and a value
    "key2": "value2:

These keys are called properties and the values can be any of the data types in JavaScript (keys have to be a string or a Symbol). Ok, so lets take a little detour as you was confused about data types.

What is a data type? To steal from Wikipedia:

In computer science and computer programming, a data type or simply type is an attribute of data which tells the compiler or interpreter how the programmer intends to use the data.

Now, this can be a simple type (primitive) like a number or more complex like an object. Now, these pairs of keys and values can be used to do almost anything. They can be used to store data so an object is a virtual representation of real things, i.e. the key value pairs describe real things like a car:

const car = {
    "colour": "red",
    "make": "Ford",
    "model": "Fiesta"
    //you get the point

Now, if you get to something else that could also be complex, such as the engine the value could be another object.

const car = {
    // properties
    "engine": {
        "name": "20B-REW",
        "Displacement": "1962"
        // etc

So when you say that data can’t have colours, no it can’t but it can represent information that means a colour to something else, be that a string for a human or a hex code, etc.

Ok, so if a function is a type of object how is it also so different? It doesn’t just store a collection of data, it actually does stuff. The big key here is something that JavaScript has called Internal Properties, these are in the object and are still under the normal key, value pair pattern of objects but they cannot be accessed by programmers in code and they are defined in the specification for the JavaScript language.

In these, there is one that stores the actual code of the function object (the name changes depending on the version of the specification) and one that is used when the function is called. So the function object is an object that describes the function, the [[ECMAScriptCode]] internal property (2015 specification) on the object (key) has a value that is the parsed code, the [[call]] internal method has a value that will evaluate and execute the code in the internal property that store it, so [[ECMAScriptCode]] in the 2015 spec. There is slightly more going on than that, you can find and look at the ECMAScript speciation for what ever version of JavaScript (aka ECMAScript) you are using to get the full picture. But that is a basic idea of how an object can represent a function, along side other properties, such as arguments and the name.

So it comes back to the basic idea of OOP that objects are collections of data the are meant to represent other things. This is often to make our own code either to think about and understand, so we can think of real world things in a programming context, the object represents it. But we’ve seen it can also be used to describe less tangible things like a function what is the scope of the function, what happens when someone tries to use the function, what is the name of the function etc.

You also asked what references are. When you create an Object (or something that is based on an object like a function or array) in JavaScript it will be stored in the computers memory, it will have a memory address. The variable will not be associated will the memory address of the object you created, instead it will hold a reference to the memory address, so when access the variable it will direct you to the memory address of the object it references. This is how multiple variables can all point to the same object and when the object is changed they all see it, there is only one copy of the object and they all redirect you to it.

Just one thing to note (as it has been stated here) everything in JavaScript is always passed by value, you cannot pass by reference in JavaScript. This is something commonly misunderstood in a lot of languages - just remember the value of the variable is a reference to an object, not the actual object. If you passed by reference, then when changing the value of the parameter in a function to something else that change would also be seen in the argument variable, i.e.:

// Lets pretend we passed by reference
let demoVar = {A:1};
function passByRef(param) {
    param = {B:2};
// demoVar would be the object {B:2}
1 Like

The key-value pair is called a property. Keys are not properties but identifiers.

To be totally correct, a property in JS is actually a key and associated attributes, of which one is for the value. Also again, calling it an identifier isn’t true, they are IdentifierNames, which may or may not be an identifier.

But yes, it is incorrect to say the keys are properties. It should have been that keys are what the properties are called, i.e. the property’s name.

Nice explanation, I learned some stuff from it as well. Just one thing though, I’m confused now about the pass by reference thing. I obviously remembered that objects are passed by reference but since you said that isn’t true I went back to the lesson on objects in the learn Javascript path on CodeCademy, and it is stated that objects are passed by reference. Have I misinterpreted something?

In regards to your example about pass by reference;

// Lets pretend we passed by reference
let demoVar = {A:1};
function passByRef(param) {
    param = {B:2};
// demoVar would be the object {B:2}

I think the way it actually works is; when passByRef is run, param (which is a variable in its own right) gets assigned a reference to the object {A:1}, and then in the code block the assignment operator simply gives param a reference to a new object {B:2}. demoVar is not affected at all in the process. Thus the final console.log(demoVar) logs {A:1} to the console. As I understand it, this is how it normally works, and is also a demonstration of pass by reference.

Pass by value and pass by reference are two general programming / computer science terms, the JavaScript spec does nothing to give any reason why these strategies should mean something different in JavaScript.

There is often a third strategy that is suggested for this behaviour, however the name isn’t agreed upon but stuff like pass by sharing, pass by object, pass by value reference (and many more) have all been suggested but there is no standard. The problem with all of these are they just describe pass by value where the value is a reference. Also the behaviour is the same as that of arrays in most languages that don’t have objects, that is to say you pass in a mutable array to a function and change it in the function and the changes will be seen outside the function, yet this is still pass by value. So while there can be a debate if it is pass by value or pass by sharing (or whatever other name you like) the described behaviour is the same so there isn’t a need for a new name in reality in my opinion.

You didn’t misunderstand the lesson, the lesson is wrong on the terminology. I think the confusion for many is with pass by value you are passing a copy to the method/function so how can changes on a copy be represented in the original. As I said in my other post you have to remember that what was copied was the reference to the actual object not the object itself. Also when passing a value type(primitives) you could still pass it by reference. How can we be passing by reference if we can’t pass value types by reference? This is where the pass by sharing suggestion comes in but we already covered that.

As an example, let’s take a house as the object, the address as the reference and people as variables.
Let’s say you own a house, you don’t actually store that house, it has a place on the earth (it’s place in memory) but you can access the house because you know how to find it via the address (the reference). Many other people will also have the address to your house, they all shares a reference to the same object. One day you decide you want to get the house painted, so you call a painter and pass them your address and they come and paint your house. The painter is like a function, it takes a copy of your address (reference) and then mutates it (changes the object). Everyone that has a reference to your address will see the your house newly painted when they access it.

So what is pass by reference? It means you change the variable that is passed into the function. If the value is a reference then you could changes the reference to look at a whole new object.

Taking our painter example, this would be like the painter giving painting a different house and then giving it to you instead of painting yours. You then live at the new house and reference that address but everyone else that had your address still holds a reference to the old house and don’t even know about your change of address and won’t see any change.

My example of pass by reference was of the behaviour of true pass by reference. But you are right for what would happen in the current behaviour/the lesson explanation, but as I say that is not pass by reference but by value (or by sharing if you so wish).

Another example with a value type (primitive):

// Pretend we passed by reference
let intA =1;

const intByRef(param) {
    param = 2;
// Would print 2.

Passing by reference doesn’t care if the type passed in is a reference type or not that isn’t what the reference part in pass by reference relates to.

I have yet to see anyone who claims it is pass by reference to actually demonstrate anything other than pass by value. It should really be described as pass by value but pass by sharing or some such would also be better than reference.

1 Like

It seems the lesson has had me bamboozled this whole time. It’s nice to know that everything is now consistent, in that it is all passed by value in Javascript. Much thanks for the explanation. I like pass by value reference the best to describe what Javascript does with objects, I think I’ll stick to that from here on.

Thank you, I have a clear idea of what an object is now, but aren’t the properties of an object basically variables? Also, I heard from somewhere that objects come from classes but I don’t know what classes are either, could you explain it?

  • A class defines a data type.
  • Variables and property identifierNames are labels.
  • Objects are the values we assign names as long as we need them.
  • The properties of an object are objects.

All objects have one type in common… 'object'. It is the top of their prototype chain. Only primitives do not have this distinction. To be seen as objects JS gives them wrapper objects of a discernible type, be it ‘number’, ‘string’ or ‘boolean’. It is the wrapper objects that inherit from their parent prototypes, in addition to the common inheritance from Object.prototype.

The next question is how does JS afix the discernible type to primitives?

This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.