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

Dmitry A. Soshnikov dmitry.soshnikov at
Sat Apr 17 05:38:01 PDT 2010

Hello David,

Saturday, April 17, 2010, 2:01:09 AM, you wrote:

>> 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.

Well, it was just quick suggestion (right-now, in-place), although as I
mentioned myself, it is debatable wethere it is (naming convention) fits
for the current ES design. All that ".", "_" and other -- looks odd
as I said myself.

But I meant not only naming convention, but that by this naming
convention this properties (symbols) will be hidden -- just like in
Python, when "_" and "__" properties become unavailable outside by
their names (although, Python just renames them by special rule
"_ClassName__property_name" -- but that doesn't matter).

So, of course it is a question not of one letter and here should be
deep analysis to provide the most applicable design.

>> 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).

Then I have to see more examples. And nevertheless, encapsulation in
its main purpose -- is increasing of abstraction. But you're talking about
already *security* hiding. Then of course should be other approach. I'd be
glad to see more examples of your "Name"s proposal -- how one part can
get access to hidden data, and another -- cannot.

> 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.

Thank you, I of course will take a detailed look on it and be glad to
see another examples of this proposal. Then maybe we can suggest also
something interesting if will completely understand how should it
look and work.


More information about the es-discuss mailing list