I recuse myself (was: Private names use cases)
On Dec 21, 2010, at 12:39 PM, Mark S. Miller wrote:
The promised separate email:
On Tue, Dec 21, 2010 at 10:20 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
It seems to me, the real point of difference here is whether or not we should add a syntactic mechanism that supports information hiding in the context of JavaScript objects. Some constituents want this, others do not.
I never said I don't want syntactic support. I said I don't like the syntax you proposed. You and Dave have now both said that you consider this to be the main issue. To me it is a minor and separate issue. Were soft fields to be adopted with your syntax, I would consider that to be an overall good outcome.
It wasn't you that I had in mind with the above statement. I have heard from several individuals that they would prefer to have no enforced information hiding (or encapsulation if you prefer that terminology).
From private email, I have even been made aware that my attempts to separate the syntax and semantics debates is perceived by some to be "a trick" to kill both the syntax and semantics of private names. I am shocked and distressed that the level of suspicion is now so high that I must cope with these suspicions. That I am against both does not make insincere my sense that they are orthogonal questions. I will point out that it occurred to me as I was writing those wiki pages that it would be strategic not to reveal my dislike of the syntax until we'd settled the semantics issues. I chose not to do so in order to avoid giving a false impression that I like the syntax. I have been open about my opinions throughout the process.
I do think there are some fundamental differences in both what problems we are trying to solve and in our approaches to a solution. There is probably even some frustration about the difficulty we seem to be having in reaching an understanding of whether or not we are addressing the same problem. However, I don't question your sincerity or think any trickery is involved.
Nevertheless, because such suspicions have arose, and because I consider only the semantics issues crucial, I will recuse myself from further discussion -- either on list or in the meetings -- of the syntax to be associated with this functionality. I will proceed as if we're all in agreement on your syntax and argue only about the semantics.
Please don't totally disengage from the syntax discussion. Most programmers understanding of the language starts with the concrete (syntax) and then proceeds to the abstract (semantics). Syntax design can have a big impact on the usability of the underlying semantics
Allen.
I never said I don't want syntactic support. I said I don't like the syntax you proposed. You and Dave have now both said that you consider this to be the main issue.
Hm, I certainly didn't intend to say that. I'm not quite sure what you're referring to that I said. I don't necessarily have a single sine-qua-non in this design space. Sorry I haven't been as clear as I should have.
There's a lot going by in this conversation, and I don't want to add too much noise, but I do want to emphasize something: the various options we've discussed all have a syntactic component, even if we separate out the |private| syntax. Brendan mentioned this in reply to David-Sarah, but I think it's worth repeating: whether in the soft fields approach or the private names approach, <expr>[<expr>] is overloaded in a new way.
Maybe that's the key sticking point for me about the soft fields approach: overloading that syntax to mean lookup in a side table is what seems like a drastic break from the intuitive model of objects. I have nothing against side tables as a programming idiom; it's when you make them look like they aren't side tables that they become confusing. Especially when you can do counter-intuitive things like add new properties to a frozen object. Of course, there are clearly use cases where you want to associate new data with a frozen object, and convenience would be helpful. I'm just not convinced that making it look like ordinary object lookup is the right programmer-interface. So yes, it's a syntax issue, but it's a syntax issue that frames the mental model, and I think that matters.
What am I saying with all this? Not sure. I'm disheartened at the level of controversy too, but I think it's worth pushing through, because as a JS programmer, I really feel the lack of private fields-or-properties (with apologies to the English language... trying to remain diplomatic here...) in day-to-day programming.
The promised separate email:
On Tue, Dec 21, 2010 at 10:20 AM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
I never said I don't want syntactic support. I said I don't like the syntax you proposed. You and Dave have now both said that you consider this to be the main issue. To me it is a minor and separate issue. Were soft fields to be adopted with your syntax, I would consider that to be an overall good outcome.