Today I did some reading relevant to the To Do list item to learn how to use the prototype object pattern as opposed to the purely closure-based method I’ve been using. Suffice it to say there’s a lot of information to digest about the subtleties of objects in general within JavaScript. The details of using public, private, and privileged members are even more subtle.
Everything I’m going to write here is true for ECMAScript 5. Version 6 has added new ways to declare objects that may be easier to deal with but I’m not using those features to maintain wider backwards compatibility. I’m pretty sure the new elements in 6 are only additions and that everything in this discussion will continue to be true. I’m formally using Babel or TypeScript just yet and, even more importantly, everything I write here is subject to revision over the next couple of posts (and beyond) as I learn and experiment with things.
Public variables (I usually refer to those as properties) can either be public or private. Public properties are declared within the constructor (closure) using this. notation. Private properties are declared using the standard var notation. Public properties are visible from anywhere except to private methods and can be modified, redefined, removed, and so on dynamically. Private properties, including the constructor’s parameters) are only visible within the constructor to private and privileged methods.
|
1 2 3 4 5 6 7 8 9 10 11 |
function ExampleObject(param1, param2) { //params are private this.publicProperty = param1; //public var privateProperty = param2; //private } ExampleObject.prototype.anotherPublicProperty = "Wilma"; var myObject = new ExampleObject("Fred","Barney"); var a = myObject.publicProperty; //"Fred" var b = myObject.privateProperty; //undefined var c = myObject.anothrPublicProperty; //"Wilma" |
The this example we see that public variables are visible outside the object and do not require setters and getters. It’s also possible to add public properties to objects using an external prototype notation.
Functions (methods) can be members of objects as well and they can be public, private, or privileged. Public methods are added externally to the constructor using the prototype notation and are visible to each other and to outside entities. They are not visible to private or privileged methods. Private entities are declared within the constructor and can only see private properties and methods. Privileged methods tie everything together. They can see privileged and private methods and are visible to public methods and each other.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
function ExampleObject(param1, param2) { //params are private this.publicProperty = param1; //public var privateProperty = param2; //private var privateMethod = function privateMethod(name) { //can drop everything up to "=" return name + " " + privateProperty; } this.privilegedMethod = function() { return this.publicProperty + " " + privateMethod("Betty"); } } ExampleObject.prototype.anotherPublicProperty = "Wilma"; ExampleObject.prototype.publicMethod = function() { return {a: this.publicProperty, b: this.anotherPublicProperty}; } var myObject = new ExampleObject("Fred","Barney"); var a = myObject.publicProperty; //"Fred" var b = myObject.privateProperty; //undefined var c = myObject.anotherPublicProperty; //"Wilma" //var d = myObject.privateMethod("Pebbles"); //error var e = myObject.privilegedMethod(); //"Fred Betty Barney var f = myObject.publicMethod(); //{a: "Fred", b: "Wilma"} |
One observation is that if we’re going to make setters and getters for private properties we’d have to write a private method for the getter and then call that from a privileged getter method, which would finally make the property’s value visible to the privileged and public methods, and then we’d have to do the same for the setter in reverse. There may be reasons to do that but I’m not sure I see any in the code I’ve been writing. If you have any guidance on this subject I’d love to hear it. That said, I can imagine other situations where it might be worthwhile to hide certain mechanisms.
Simulation codes often place a premium on speed and we’d want to avoid this kind of thunking up and down if we can. We’ve also discussed previously that memory usage can be equally important, especially in systems with lots and lots of entities. I’m thinking that if the properties are all declared as public and the methods as public also, we make the instantiated objects as small as possible since they carry only data and ensure that code isn’t duplicated if it doesn’t need to be. (And by “duplicated” I mean references to the functions being stored with the instantiations, not the entire code — I think. It’s hard to find solid documentation on what’s actually happening in the different implementations, which is annoying. That said, I’ve identified some possible leads as to how this question can be answered and will report back with my findings.) Tomorrow I’ll try to convert one of the component objects and see how it goes. We can also discuss how inheritance might be used in the component objects since there’s a lot of duplication there, but that’s not the problem we’re trying to solve right now…
One final note: In theory you’re supposed to declare a private variable called that, which is supposed to be set equal to this, in order to make the object available to private methods, but I don’t know if that requirement is still in effect. Adding it in different places didn’t seem to affect anything and omitting it doesn’t keep anything from working (in my limited tests). See this important article from 2001.