Le 28/08/2012 15:38, Kevin Smith a écrit :
Apologies in advance for the length...
Don't. We're here to discuss as the mailing-list name suggests. And if
what you need to say is long, so be it.
A huge share of this complexity has been removed in recent
discussions [1]. Conclusions seem to have reach consensus on
es-discuss, but nothing has been officially accepted by TC39
As I understand it, the solution arrived at was to provide a (possibly
updatable) collection of private name objects to the Proxy constructor
and let the engine take care of the details. That sounds good, and
good work!
Exactly. I'm glad there is one more fan of the proposal :-)
What do you mean? Private name allow to do mixins without
collision. It seems to reduce the complexity than increasing it in
my opinion.
Unique (non-private) names offer mixins without collisions. But any
general mixin utility will fail if the source object relies on
privately named methods for its functionality:
(code snippet)
Neither the destination object nor the library function "mixin" has
access to the private name, and therefore the privately named method
will not get copied to the destination object, and the mixin will fail.
Clearly the solution above would be to use a unique name, instead of a
private name.
Indeed.
But that begs the question: why do we need private, secured names at
all? They complicate the object model without a compelling use case,
as far as I can tell. If there are use cases, let's see them.
Private names enable easy encapsulation & code sharing at the same time
(which is awkward at best nowadays).
As a result of the current awkwardness, developer sacrifice
encapsulation by using publicly accessible fields using the _field
convention. I could name dozens of Node.js library doing that.
And sometimes, developers use a private field while they shouldn't, but
it makes their life easier, and abstraction leak, etc.
It all start because of a fundamental missing piece in the language that
is the ability to add a private property to an object. Not socially
private as per the _field convention. I mean actually private, enforced
by the runtime.
In any situation where you want to *really* secure access to data or
code, the ergonomics of your code is going to be the least of your
worries.
I disagree. A good part of the work toward securing an application is
reviewing it. The easier the review is, the less likely you are to leave
holes behind. The ergonomics of the code is a security feature.
Security is just generally difficult, and that "soft-tissue" cost will
have to be borne by the developer whether they use WeakMaps or private
names or closures or whatever. Why complicate the object model, and
in the process invalidate the current maxim that all properties are
reflective, when the weight will still fall on the developer anyway?
I arrived on es-discuss at a time where private names had been decided
to be the mecanism that answer all above-listed constraints. It seems to
do the job. I have intuitive concerns about how to use them in large
scale applications and preserve proper code sharing, but nothing
concrete to either validate nor invalidate this intuition. In a
nutshell, I'm wondering whether private names will be easy to use in
complex cases.
I'm not specifically against the idea of complicating the object model
if the benefit is developers stopping _fields. I am open anyway to see
if there is an idea that's alternative to private name and would solve
all above constraints.
There is still time since no one has implemented private names (or
symbols as it's their new name which I'm still not used to) yet.
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
