{"id":11,"date":"2016-02-09T04:49:01","date_gmt":"2016-02-09T04:49:01","guid":{"rendered":"http:\/\/www.onux.com\/jspp\/blog\/?p=11"},"modified":"2016-05-01T23:50:54","modified_gmt":"2016-05-01T23:50:54","slug":"design-notes-const","status":"publish","type":"post","link":"https:\/\/www.onux.com\/jspp\/blog\/design-notes-const\/","title":{"rendered":"Design Notes: ‘const’"},"content":{"rendered":"

JS++ does not implement a const<\/code> keyword. This was a design decision.<\/p>\n

For instance, consider the following ECMAScript 6\u00a0code:<\/p>\n

\r\nconst x = {};\r\n\/\/ Adding a new property, not \"constant\" at all\r\nx.foo = 1;\r\n\/\/ Changing the value of an existing property; once again, not \"constant\"\r\nx.foo = 2;\r\n\r\nx.foo; \/\/ 2\r\n<\/pre>\n
The variable x<\/code> is declared as a constant using the const<\/code> keyword. However, it very clearly is not constant<\/em> (e.g. mathematical constants, which are typically our first exposure to constants). Where references are concerned, const<\/code> does not actually create a “constant” and should thus be regarded as either a misnomer, and, in a worst case, should be disallowed as a matter of best practice in order to discourage semantic confusion<\/a> and – consequently – bugs.<\/p>\n
The situation is bad enough that Brendan Eich, the creator of JavaScript, even retweeted a blog post about this confusion:<\/p>\n
\"es6-const\"<\/p>\n
Instead, JS++ uses the final<\/code> keyword. final<\/code> prevents any further assignments to a variable; in other words, this is the last and “final” assignment. Thus, while the reference can be modified, the actual variable is still referring to that same reference. It was a final reference, and the reference we were referring to cannot be changed. Simple semantics and functionally identical, but it can go a long way in complex projects.<\/p>\n
You never know if you’ll have a team member that doesn’t know the nuances of const<\/code>, and – going back to semantic confusion – naturally assumes it works a certain way without looking it up and researching it. This is a common problem with JavaScript, where a lot of developers assumed it would be like C\/C++ or Java and, thus, did not spend too much (if any) time learning it properly. Personally, I was guilty of much of the same in my early days. const<\/code> being introduced into the official language specification did not take this behavioral issue into account and risks exacerbating the problem. (ASIDE: Issues like this, while minor and seemingly innocuous on the surface, can create exponentially many problems in larger applications and forced the hand for JS++ to break away from the ECMAScript specification – among a host of other problems.)<\/p>\n
Yes, languages like C++\u00a0get away with using const<\/code>. However, it can be argued that it’s so deeply embedded into the language in special ways it almost forces programmers to read the documentation and learn about it in depth (see: “const correctness” in C++). When you see:<\/p>\n
\r\nconst int *const ptr = &x;\r\n<\/pre>\n
You begin to realize that there is more to const<\/code> in C++ than you may have figured out through a pure dictionary definition. This is not so when you see this:<\/p>\n
\r\nconst x = {};\r\n<\/pre>\n
The latter example (in JavaScript) does not encourage you to read the documentation or best practices. When we make assumptions that we “just know,” it can be dangerous.<\/p>\n
We made a design decision based on experience and observation in the hope that final<\/code> will be better because it doesn’t necessarily encourage the “I just know<\/em> what it does” attitude. When it does, they should already be familiar with how it works from Java – a correct, consistent, non-confusing, and – most importantly – safe expectation.<\/p>\n","protected":false},"excerpt":{"rendered":"
JS++ does not implement a const keyword. This was a design decision. For instance, consider the following ECMAScript 6\u00a0code: const x = {}; \/\/ Adding a new property, not “constant” at all x.foo = 1; \/\/ Changing the value of an existing property; once again, not “constant” x.foo = 2; x.foo; \/\/ 2 The variable … Continue reading “Design Notes: ‘const’”<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[3,2],"tags":[],"_links":{"self":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/11"}],"collection":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/comments?post=11"}],"version-history":[{"count":7,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/11\/revisions"}],"predecessor-version":[{"id":39,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/posts\/11\/revisions\/39"}],"wp:attachment":[{"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/media?parent=11"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/categories?post=11"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.onux.com\/jspp\/blog\/wp-json\/wp\/v2\/tags?post=11"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}