names [Was: Approach of new Object methods in ES5]

David Herman dherman at
Fri Apr 16 15:01:09 PDT 2010

> Still naming convention (the thing which ES doesn't use -- and in vain)
> is a good and elegant approach. That is Python (or even Ruby)
> uses.

Brendan already described to you some of the problems with name-mangling techniques, and we could argue over whether naming conventions are indeed "elegant" programming techniques. But they are useless as language features for information hiding. If people want to use naming conventions to suggest privacy they can already do so today, with no additional language extensions.

> var foo = {x: 10, :y: 20} // although...
> where :y - is your "private" "Name" symbol.
> Choose any:
> ...
> and so on, there are many interesting naming conventions (which are
> not yet "borrowed" by backward compatibility).

Any of these would merely suggest privacy, without enforcing it. This comes with no guarantees whatsoever. The purpose of the private names proposal is to provide a mechanism for creating *guaranteed* private object properties. If the creator of the object does not share the name value, then no one else can get to the property. What you have suggested is just a convention.

> How naming convention will help? -- in any position in code we can
> presiseally say what access level this property has.

No, you can't. All you've done is change the syntax. There's no behavioral difference that ensures that one part of the code can access the "private" data and another can't.

> Leaving naming conventions (if you will) it is also possible to use
> this "private" keyword in this form:

The private names proposal already includes a declarative syntax for creating private names.

> let obj = {
>  private:
>    foo: 42,
>    bar: 41
>  public:
>    baz: 43
>    getFoo: lambda() this.baz +;
> };
> ...
> = 44; // Error, "bar" is private ?

If "private" is an attribute of the slot but the name is still public, then you have not entirely hidden your data representation. You still end up with name contention (no one can use the property name "bar" now) and you don't get full information hiding (clients can see that you have a property called "bar" and change their behavior because of it).

You also haven't said anything about what parts of the code do have access to the private properties and what parts of the code don't. If you don't see why this is important, then trust me -- it's tricky in a language where objects and functions can be arbitrarily lexically nested and functions can be dynamically added and removed from objects.

These issues are addressed by the names proposal-- please do take a look.


More information about the es-discuss mailing list