• We’re currently investigating an issue related to the forum theme and styling that is impacting page layout and visual formatting. The problem has been identified, and we are actively working on a resolution. There is no impact to user data or functionality, this is strictly a front-end display issue. We’ll post an update once the fix has been deployed. Thanks for your patience while we get this sorted.

JavaScript: why colon (:) and not equals (=)

fuzzybabybunny

fuzzybabybunny

Moderator<br>Digital & Video Cameras
Moderator
I'm starting to learn JS and I've noticed this that makes me frustrated:

Code: 
var myStruct = {
   myValue: "value"
};

WTF?

So you're setting the variable myStruct EQUAL to the stuff in the brackets.

But then you're also setting myValue EQUAL to "value"

So why use the colon? Wouldn't it be more consistent, sensicle, and intuitive to just do:

Code: 
var myStruct = {
   myValue = "value"
};
 
Mark is right. It's just the standard for JSON, so everything is listed as key/value pairs.
When you think of it that way, it would look kind of strange to transmit JSON objects full of equal signs. Especially when you start having objects inside of objects. It would look something like this:

Code: 
var someObject = {
   string1 = "value",
   nestedObject = {
       string2 = "foo",
       someOtherString = "whatver",
       someNumber = 5,
       yetAnotherNestedObject = {
           string3 = "this looks ugly...",
           string 4= "really ugly."
       }
   },
   string5 = "etc"
};

Maybe it's just because I'm used to it, but I find the colons much more readable when I am glancing at JSON. It just seems to translate better to "key: value", at least in my mind.
 
You are using the javascript object literal notation, so writing:

Code: 
var myStruct = {    myValue: "value" };
It's exactly the same as writing:

Code: 
var myStruct = new Object();
myStruct.myValue = "value";
So why the object literal notation has become a standard way to define objects in js? Because it's shorter, it's easier to create more structured objects on the fly and there is no scope resolution.

And please, do not try to make any further comparison between those 2 languages. One is a scripting language, the other is an imperative procedural language. It doesn't make any sense to compare a dog with a car...

I hope to have clarified some things up 🙂
 
Last edited:
And this notation isn't just used in javascript or json, it's a common way to express the key value pair construct.

In objective-c for example you could do:

Code: 
NSDictionary *dictionary = @{ @"value" : @YES }
 
mosco said:
And this notation isn't just used in javascript or json, it's a common way to express the key value pair construct.

In objective-c for example you could do:

Code: 
NSDictionary *dictionary = @{ @"value" : @YES }
Click to expand...

Good point. Same syntax for dictionaries in Python:

Code: 
colors = {'red':0xff0000, 'blue':0x0000ff}
 
C/C++ has = for assignment of a value and == for testing for equality. That leads to trivial errors too. Whose syntax has the := for assignment operator?
 
As explained in this post, ":" is used in a dictionary that is a very similar to a class/struct. However, you can "=" in a constructor that creates a more "real" object:

Code: 
    function myStruct(value) {
      this.myValue = value;
    }
 
You apes just don't get it. 😛 My fellow bunny didn't ask "What am I doing?" or "How do I do this?". The question was "Why does javascript they require it this way?", coupled with the observation that it Just. Doesn't. Make. Sense.

fuzzybabybunny is a novice javascripter and I'm a veteran javascripter and we both think alike on this.

I have no answer to "Why?" but I can also see no reason why the syntax for object initialisation has to use colons instead of equals. The parsing would work whichever token was used. I'd go further and say that it doesn't need to use commas instead of semicolons to terminate a property initialisation.

For me, this crops up every now and then when I'm coding a new area of functionality. I'll start with some code which sets up some variables and then go on to use them. As the functionality grows I might add some more variables and then at some point it'll look like it may be handier to have them in an object (which may, further down the road, grow into a class).

I then have to turn something that looks like
Code: 
var foo = 6295141.3;
var bar = "Right you are";
var the = "Wednesday";
var elephant = 0.5;
into
Code: 
var obbjy = {
    foo: 6295141.3,
    bar: "Right you are",
    the: "Wednesday",
    elephant: 0.5
    };

Now wouldn't it be a lot easier if the object initialisation used equals and the terminator was semicolon? Then, rather than faffing about editing each and every assignment, all I'd need to do would be to take out the vars, pop some braces around the lot and assign that to the new object variable.


ps. Anyone talking about JSON is barking up the wrong tree. JSON is relatively new. It's a subset of javascript but it has nothing to with javascript's design. The only design decision of JSON is the requirement for inefficiency, namely the use of quotes around property names that do not need them. { "UnnecessaryQuotes": true }
 
devBunny said:
You apes just don't get it. 😛 My fellow bunny didn't ask "What am I doing?" or "How do I do this?". The question was "Why does javascript they require it this way?", coupled with the observation that it Just. Doesn't. Make. Sense.

fuzzybabybunny is a novice javascripter and I'm a veteran javascripter and we both think alike on this.

I have no answer to "Why?" but I can also see no reason why the syntax for object initialisation has to use colons instead of equals. The parsing would work whichever token was used. I'd go further and say that it doesn't need to use commas instead of semicolons to terminate a property initialisation.

For me, this crops up every now and then when I'm coding a new area of functionality. I'll start with some code which sets up some variables and then go on to use them. As the functionality grows I might add some more variables and then at some point it'll look like it may be handier to have them in an object (which may, further down the road, grow into a class).

I then have to turn something that looks like
Code: 
var foo = 6295141.3;
var bar = "Right you are";
var the = "Wednesday";
var elephant = 0.5;
into
Code: 
var obbjy = {
    foo: 6295141.3,
    bar: "Right you are",
    the: "Wednesday",
    elephant: 0.5
    };

Now wouldn't it be a lot easier if the object initialisation used equals and the terminator was semicolon? Then, rather than faffing about editing each and every assignment, all I'd need to do would be to take out the vars, pop some braces around the lot and assign that to the new object variable.


ps. Anyone talking about JSON is barking up the wrong tree. JSON is relatively new. It's a subset of javascript but it has nothing to with javascript's design. The only design decision of JSON is the requirement for inefficiency, namely the use of quotes around property names that do not need them. { "UnnecessaryQuotes": true }
Click to expand...
Agreed with the above and will add that that just about everyone can quickly do Ctrl+d to set multi cursors on every sequence of " =" (VS Code) and then change it all by typing a single ":". I'm sure other editors have similar shortcuts. There are a tone of productivity tools for working with text, and changing equals for colons is rendered insignificant thanks to them.
 
Everyone is providing really technical examples but I think an analogy and history would be better.

JavaScript's spec says the equal sign will be used as an assignment operator.
JSON's spec says the colon will be used to denote key/value pairs.

These are two different specs, and they serve two different purposes.

You're kinda asking why "cat = gato" isn't just "cat = cat" - the grammar and spelling of the two specs being different is definitely something that is a possibility, so it shouldn't be *such* a surprise right off the bat.

So the question then is naturally: why did the spec for one choose assignment operator to be equals and the other a colon for nearly the same idea?

JavaScript is a C-based language developed in 1995. Assigning variables with the equals operator dates back to very early programming and that syntax simply was carried forward.

JSON was developed in around the year 2000 (and thus, not in tandem with JS and so they didn't just switch up operators on you during the same period of development if that's what you thought).

And historically, key/value pairs were denoted with colons and that's was carried forward.
See: https://en.wikipedia.org/wiki/JSON for their goals and requirements, but it definitely wasn't chosen this way to be intentionally confusing.

Further - I think semantically a colon makes more sense in JSON. DevBunny is correct that any token can be used when parsing and in the design but when thinking about it what it actually means - in the programmatic sense, you are assigning a value to a variable - that's historically sound. Equals operator.

But in JSON, you are declaring some attribute of something is a particular value.
 
Last edited:
fuzzybabybunny said:
I'm starting to learn JS and I've noticed this that makes me frustrated:

Code: 
var myStruct = {
   myValue: "value"
};

WTF?

So you're setting the variable myStruct EQUAL to the stuff in the brackets.

But then you're also setting myValue EQUAL to "value"

So why use the colon? Wouldn't it be more consistent, sensicle, and intuitive to just do:

Code: 
var myStruct = {
   myValue = "value"
};
Click to expand...
Very good point! It is something that has irked me for an eternity as well, and that's why in the latest iteration of my own programming language (T) that transpiles to JavaScript, I have unified assignment into ':' and in the process also got rid of the equally (no pun intended) weird '==' operator.

So, in my language, your example would be:

var myStruct:
myValue: "value"

var foo: 1

if foo = 1
console.log('test')

Keep questioning the status quo!
 
You must log in or register to reply here.

TRENDING THREADS

Back
Top