{"id":32,"date":"2010-12-10T17:45:51","date_gmt":"2010-12-11T01:45:51","guid":{"rendered":"http:\/\/www.wirfs-brock.com\/allen\/?p=32"},"modified":"2022-04-14T16:57:42","modified_gmt":"2022-04-14T23:57:42","slug":"an-ecmascript-information-hiding-proposal","status":"publish","type":"post","link":"https:\/\/wirfs-brock.com\/allen\/posts\/32","title":{"rendered":"An Information Hiding Proposal for ECMAScript"},"content":{"rendered":"

One of the goals for ECMAScript Harmony<\/a>, the project to define the next versions of the JavaScript standard, is to make JavaScript a better language for writing complex application.\u00a0 Better support for object-oriented encapsulation, information hiding, and abstraction should help JavaScript programmer deal with such applications.<\/p>\n

Today, I\u2019m going to talk specifically about a proposal for better information hiding in JavaScript.\u00a0 As I use the term, information hiding means that an object should clearly separate its stable public interface from its private implementation details. Properties that exist solely as implementation details should be hidden from \u201cusers\u201d of that object.<\/p>\n

JavaScript today does not provide much support for information hiding.\u00a0 All properties have public string names and there is no language mechanism to tag\u00a0 public or private properties.\u00a0 Some programmers use naming conventions as a very weak form of information hiding.\u00a0 Programmers looking for a stronger form often abandon the use of implementation properties (and prototype inheritance) and use closure capture to represent implementation state.<\/p>\n

When evolving a language to address some specific program, it is natural to look at how other languages approach that problem.\u00a0 Many people are familiar with information hiding in C++ or Java and may assume that JavaScript should implement information hiding in that same familiar way. In those languages “private” is an attribute of a member (field or method) of a class.\u00a0 It means that a private member is only accessible to other members of the same class. The fact that member definitions are encapsulated together as a class definitions is key to this approach to information hiding.<\/p>\n

Java-like information hiding is not a particularly good match to the JavaScript object model where the structure of an object is much more dynamic and\u00a0 methods functions can be dynamically associated or disassociated with an object and shared by many different kinds of objects.<\/p>\n

Let\u2019s look at a different approach to information hiding that may be a better fit to JavaScript. In this approach “private” is an attribute of a property name, rather than of an actual property.\u00a0 Only code that knows a “private name” can use that name to create or access a property of any object. It is knowledge of the name that is controlled rather than accessibility to the property.<\/p>\n

Let\u2019s look at how this might look in code.\u00a0 First assume that a private<\/code> declaration creates a unique private name and associates it with a local identifier that provides access to that unique name:<\/p>\n

private implDetail;<\/code><\/pre>\n
The local identifier can then be used to create object properties whose \u201ckey\u201d is that unique private name and also to reference such properties:<\/p>\n
function MyObj() {\r\n   private implDetail;\r\n   this.implDetail=42;\r\n   this.answer = function() {return this.implDetail};\r\n}<\/code><\/pre>\n
Remember that the name of the property created above is not actually the string \"implDetail\"<\/code> but instead it is a unique value that was created by the private<\/code> declaration. The identifier implDetail<\/code> is just a lexically scoped handle that is used to access that private name value. So:<\/p>\n
var obj=new MyObj();<\/code> alert(obj[\"implDetail\");\/\/\"undefined\" alert(obj.implDetail);\u00a0 \/\/\"undefined\"\r\n<\/code>alert(obj.answer());\u00a0 \/\/\"42\"\r\n<\/code><\/pre>\n
For the first alert<\/code>, the message is \"undefined\"<\/code> because obj<\/code> does not have a property with the sting name \"implDetail\"<\/code>.\u00a0 Instead it has a property with a private name that does not match that string. In the second alert<\/code> the statement is not within the lexical scope of the private<\/code> declaration\u00a0 (within the constructor MyObj<\/code>) so the property identifier implDetail<\/code> does not correspond to the private name.\u00a0 Finally, the third alert<\/code> calls a method which does have access to the private name and it can return the value of the property.<\/p>\n
This is a very powerful mechanism for adding information hiding to the JavaScript object model.\u00a0 By following various usage patterns it is possible to implement the equivalent of both instance private and \u201cclass\u201d private properties and also the equivalent of C++ friends visibility.\u00a0 It can also be used to make extensions to built-in objects such as Object.prototype in a manner that is guaranteed not to collide with independently developed code that might try to make similar extensions.<\/p>\n
A complete strawman proposal<\/a> for this style of information hiding has been prepared for EcmaScript Harmony. It covers many more the technical details and provides many more complete examples of how the feature could be used.\u00a0 Take a look and let me know what you think.\u00a0 We’ll be discussing it in the standards committee but I’d like to get feedback from a broader range of JavaScript programmers. Does this proposal address your information hiding needs?\u00a0 Does it fit well with the language as you use it?<\/p>\n","protected":false},"excerpt":{"rendered":"
One of the goals for ECMAScript Harmony, the project to define the next versions of the JavaScript standard, is to make JavaScript a better language for writing complex application.\u00a0 Better support for object-oriented encapsulation, information hiding, and abstraction should help JavaScript programmer deal with such applications. Today, I\u2019m going to talk specifically about a proposal […]<\/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,12,11,13,14],"_links":{"self":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/32"}],"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=32"}],"version-history":[{"count":7,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/32\/revisions"}],"predecessor-version":[{"id":1165,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/posts\/32\/revisions\/1165"}],"wp:attachment":[{"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/media?parent=32"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/categories?post=32"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/wirfs-brock.com\/allen\/wp-json\/wp\/v2\/tags?post=32"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}