3

I'm just wondering if public fields (i.e. those not scoped inside the constructor's closure) are acceptable in JavaScript. While the usual mantra is "don't use public fields, use accessors or properties", I noticed that properties are not yet supported widely across all browsers (IE).

Other languages similar in vein to JavaScript's "everything is public" like Python don't seem to care too much about information hiding and public fields, even those not decorated with properties. So, is it okay to do this in JavaScript?

Example

"Private":

var Class = function()
{
    var field = null;
    this.getField = function() { return field; };
    this.setField = function(value) { field = value; };
};

Public:

var Class = function()
{
    this.field = null;
};
Community
  • 1
  • 1

2 Answers2

5

We don't care about hiding public information since the source is open and interpreted on the fly by the client.

Properties are not used (they are also slow) commonly and getter functions are also uncommon. There is no private keyword in Javascript, so wrapping each publicly-accessible prop in a getter/setter method pair would be overkill.

Just write out properties to your objects.

It is a common practice, maybe even a convention, to prefix internal properties with a _ to indicate that they are not intended to be changed or examined by callers.

For example :

function Foo() { 
    this._meta = {};  // internal use only
    this.prop2 = {};  // public use ok
}

Foo.prototype.meta = function(key, val) {
    if (val !== undefined) {
        this._meta[key] = val;
    } else {
        return this._meta[key];
    }
};

This code shows a public method meta and an internal property _meta. The property can be accessed, but developers should realize that if they modify it they can corrupt state.

Cheeso
  • 189,189
  • 101
  • 473
  • 713
Raynos
  • 166,823
  • 56
  • 351
  • 396
  • @the_drow sorry, the state of that was appaling. I should avoid writing answers at 1.30am. – Raynos May 09 '11 at 01:15
  • @the_drow you did a good service improving the text, but it's 'tamper', not 'temper'. – entonio May 09 '11 at 01:18
  • @Raynos we do care about hiding info not because the source is open but because we wanna reduce bugs. Encapsulation decouples us from implementation details so we can change how stuff work internally without changing our classes APIs. my rule of thumb is: the more i expose publicly, the more complexity & coupling i have. – danfromisrael Dec 24 '13 at 18:18
1

JavaScript is JavaScript, not any other language. People coming from Java have this tendency to assume everything should work like Java. That's wrong. JavaScript is in fact so far away from Java that few of their structural rules are similar. JavaScript is a prototype-oriented, loosely typed functional language, and as such it can mimic Java to an extent, but there is no reason at all why it should. Generally speaking, if you don't find a cros-language, common-sense reason for a certain mantra regarding JavaScript, ignore it.

entonio
  • 2,143
  • 1
  • 17
  • 27
  • It's not that -- I have never known Java, ever, but I've known encapsulation to be one of the core pillars of OOP. –  May 09 '11 at 03:40
  • 1
    But JavaScript isn't OOP, it's prototype-oriented, and encapsulation matters more on a conceptual level - it's the responsibility of an object to handle its own affairs, think API design - than on a mechanistic one - an accessor that just exposes a non-public variable is just the same (encapsulation-wise) as having the variable public. Accessors/properties are in fact a violation of encapsulation since they nearly always provide you access to the innards of the object rather than telling it to do something - in the cases they do tell it to do something, they're often frowned upon as confusing. – entonio May 09 '11 at 11:35