At the core of the JavaScript language is its “object model”. An object model defines the object abstraction of an language.\u00a0 It tells users how to think about objects in a language — how are objects composed and what they can do.\u00a0 It also tells language implementers what they must manifest as an object to users of the language.<\/p>\n
JavaScript has a very simple object model.\u00a0 An object is essentially just a set of key\/value pairs called properties where the keys are string values.\u00a0 In addition each object has an “inherits properties from” relationship with another object.\u00a0 Some users and some implementers actually think in terms of a slightly more complex object model where in addition to string key\/value pair properties an object may have indexed properties where the keys are integers.\u00a0 However, that elaboration isn’t really essential to the understanding of the JavaScript object model because such integer keys can be understood in terms of their string representations.<\/p>\n
Developers of JavaScript implementations spend a lot of time designing ways to optimizing their implementation of the JavaScript object model.\u00a0\u00a0 The simplicity of the object model allows for a very simple implementation, but such simple implementations will typically have very poor performance.\u00a0 In order to have excellent performance implementers need to develop mechanisms that optimize the implementation while still maintaining the JavaScript programmer’s perception of it simple basic object model.\u00a0 These mechanisms typically include complex caching and analysis techniques that try to transparently eliminate most of the dynamic overhead of the object model.<\/p>\n
The object model defines many programers’ understanding of JavaScript and it plays a central role\u00a0 in the design of JavaScript implementations. For these reasons, any major proposal to extend JavaScript needs to be critically examined for its impact upon the existing JavaScript object mode.\u00a0 If the extension requires a major change to the object model, it may be difficult for programers to understand and use.\u00a0 For implementers, even seemly simple object model changes may require significant redesign of existing optimization mechanisms and the invention of new techniques.<\/p>\n
When possible, it is probably better to try to support a new requirement by extending some existing characteristic of the object model rather than by adding something that is totally new and unrelated to anything in the current object model.\u00a0 Such extensions are more likely to be understood by programmers and to most easily fit into existing implementation designs.\u00a0 For example, ECMAScript 5 added the concept of accessor (getter\/setter) properties to the object model.\u00a0 It did this by extending what can constitute the “value” part of a property.\u00a0 Similarly, the Private Names<\/a> proposal for ECMAScript Harmony extends what can constitute the “key” part of a property.\u00a0 Both proposal are similar in that they building upon preexisting object property characteristics.\u00a0 They don’t add major new concepts to the object model that are not directly related to properties.<\/p>\n There may be future situations that justify the conceptual and implementation cost of extending the JavaScript object model with concepts that are not related to properties.\u00a0 However, the likely benefit of such an extension needs to be very large. For that reason, I want to propose a principle that any designer of a JavaScript extension should use as a starting point.\u00a0 Try to work within the basic key\/value pair property and prototype inheritance design of the current JavaScript model. Only introduce new non-property concepts into the object model as a last resort.<\/p>\n","protected":false},"excerpt":{"rendered":" At the core of the JavaScript language is its “object model”. An object model defines the object abstraction of an language.\u00a0 It tells users how to think about objects in a language — how are objects composed and what they can do.\u00a0 It also tells language implementers what they must manifest as an object to […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[6,8],"tags":[9,15,60,13,19,14],"_links":{"self":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/43"}],"collection":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/comments?post=43"}],"version-history":[{"count":2,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/43\/revisions"}],"predecessor-version":[{"id":45,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/43\/revisions\/45"}],"wp:attachment":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/media?parent=43"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/categories?post=43"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/tags?post=43"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}