New private names proposal [repost]
On Dec 21, 2010, at 10:41 PM, David-Sarah Hopwood wrote:
Again you seem to be confusing the "inherited soft fields" proposal with the separate proposal on desugaring the private name syntax to inherited soft fields.
I think I may have been misunderstanding what Mark was actually proposing/advocating, then. I'm happy to be disabused of my mis-reading.
But on re-reading, I still can't quite make sense of the "Can we subsume Names?" section. There are two syntactic components to the private names proposal:
(1) the bracket-notation is generalized to recognize private name values to look for private properties
(2) the dot-notation and colon-notation are generalized to use private names when their property name is bound by a |private| declaration
But the "Can we subsume Names?" subsection seems to mix these two cases up. To match up with (1), you'd need to interpret all bracket notation as a potential lookup of a soft field, i.e. something like:
e1[e2] ~~>
let (t1 = e1, t2 = e2) {
=> t2 instanceof SoftField
? t2.get(t1)
: t1[t2]
}
(where the rewritten brackets are the "true" brackets, i.e., not re-desugared).
On 2010-12-21 22:12, Brendan Eich wrote:
Please retain all relevant attribution lines.
You said "under private names" here, but it should actually be "under the syntax proposed for private names". It applies to that syntax with either the soft fields or private names semantics.
They do not.
Again you seem to be confusing the "inherited soft fields" proposal with the separate proposal on desugaring the private name syntax to inherited soft fields.
The matter at hand is how the proposed syntax changes affect the semantic equivalences of ECMAScript. I argued against the syntax changes (including those to the square bracket operator) on that basis. Now you seem to be arguing as though I supported the syntax changes. To be clear, I do not support the currently proposed change to how square brackets work in JS, regardless of whether that change is specified on top of the soft fields semantics or the private names semantics. I know that some people consider it to be an improvement in usability, and I disagree that it is sufficient improvement to justify the increase in language complexity. There may be alternative syntaxes that obtain a similar or better usability improvement with a smaller increase in complexity; I hope so.
(One thing is clear to me; driving experts like MarkM away from participating in syntax discussions is not going to help with that. Please reconsider, Mark.)
This has absolutely nothing to do with weak maps. We're talking about the consequences of the syntax changes, on top of either proposal.
[...]
<sarcasm>
Oh, OK, it obviously doesn't matter what we add to the language, it's all the same. Library abstractions, new syntax, major changes in semantics, who cares? Something new is something new. Let's just roll a bunch of dice and pick proposals at random. </sarcasm>
Sheesh. A library class, specified in terms of existing language constructs, is not the same as a new primitive construct, and does not have the same consequences for language complexity.
A possible convention for naming variables holding private names. It doesn't matter, you're picking on details.
I gave clear technical arguments in that post. If you want to disagree with them, disagree with specific arguments, rather than painting me as an absolutist. (I'm not.)
Tell you what, I'll debate based on the things I think are important, and you debate based on the things you think are important. Agreed?
Good, that's a start.
To be clear, it's not the syntax itself, but the parallel namespace introduced by 'private x' that I find problematic in terms of both specification complexity, and conceptual complexity for programmers.
It isn't at all clear that there aren't alternative syntaxes that would achieve the usability benefit while not being subject to the criticisms that have been made of the current syntax proposal. Lasse Reichstein posted some possibilities (.# or [#]). The syntax design space has been barely explored in the discussion so far.
It's clear how to do that for the soft field semantics, which are defined as a library abstraction.
How do the proponents of private names propose to do that? (This is a technical question, not a rhetorical one.)
I can't parse that sentence; please clarify.
Little or nothing in VM implementation is trivial. I don't agree with the implication that the soft fields semantics are more difficult to implement than the private names semantics.
There is a separate discussion to be had about whether the form of executable specification MarkM has used (not to be confused with the semantics) is the best form to use for any final spec. Personally, I like this form of specification: I think it is clear, concise (which aids holding the full specification of a feature in short-term memory), easy to reason about relative to other approaches, useful for prototyping, and useful for testing.
I don't mind at all that the correspondance with the implementation is less direct than it would be in a more operational style; implementors often need to handle less direct mappings than this, and I don't expect a language specification to be a literal description of how a language is implemented in general (excluding naive reference implementations).
We disagree, but yes, let's hear from more implementors.
How is it an abstraction leak? The abstraction is designed to allow this; it's not an accident (I'm fairly sure, without mind-reading MarkM).
With private names, the inability to "extend" frozen objects with private fields is a significant limitation.
"that changes how square brackets work in JS" is out of place here; we are discussing issues that remain after separating syntax, to the extent possible. In the inherited soft field proposal by itself, the syntax is 'field.get(obj)' and there is no magic. That is the proposal that I favour, absent some better proposal for the syntax.
If we compare both proposals with the additional syntax, they are equally "magical"; the only difference is whether the magic is built-in or the result of a desugaring.
As I said earlier, designers of secure subsets would prefer that this leak not exist in the first place, rather than having to plug it. Regardless of your statements above, this is not an absolutist position; the onus is on proponents of weak encapsulation to say why it is useful to have the leak (by technical argument, not just some vague philosophical position against strong encapsulation).
Yes, probably. That was my aim in starting the 'Strong vs weak encapsulation' thread, anyway.
Right, that is certainly the simplest way to plug the leak.
Yes.
With a SecurityManager check. I seem to remember security vulnerabilities in that area in previous versions; I'll try to find a reference.
The Joe-E object-capability subset of Java blocks access to the standard reflection APIs, since the security policy applied to them is not what is needed for an objcap language.
As far as I can see, the motivation for soft fields as an encapsulation mechanism (as opposed to for avoiding name clashes) applies to cases where the intended visibility is something other than each object's fields being private to that object. As MarkM has also said, the latter case is indeed better handled by lexical closure encapsulation.
Right. The syntactic and semantic proposals for soft fields are already separated; it is only private names proposal that does not separate syntax and semantics. It would be helpful to fix that, although I'm not sure it is possible to completely separate the syntax and semantics of the parallel namespace for private names.