> 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.
http://wiki.ecmascript.org/doku.php?id=strawman:names
> let obj = {
> private:
> foo: 42,
> bar: 41
>
> public:
> baz: 43
> getFoo: lambda() this.baz + this.bar;
> };
> ...
> obj.bar = 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.
Thanks,
Dave
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
