David Bruant wrote:
Le 20/01/2013 21:53, Brendan Eich a écrit :
Allen Wirfs-Brock wrote:
We we were going to talk about adding support for addition semantics
to classes we should start at the level of the object model. Not
with syntax. ES6 class syntax is good because it is defined in terms
of the object model and more basic operations that are defined in
the language. You don't have to use class syntax to define a class
equivalent. So, if we are going to introduce private object state
the first step is to define how it works at the object model level.
Cutting there to dodge the controversy over private-in-class based on
weak maps, to divide and conquer in the meta-discussion with David.
Here I agree with you, and we have talked in the past of the perils
of "Scenario Solving" by adding just-so syntax with novel semantics,
which is not decomposed into orthogonal primitives. You saw that in a
past life (VB5, cough) and it made messes, even though the intentions
(serving developer problem-scenarios) were good.
I'm too new to the programming language world, so I don't have this
context, but I'm curious. Do you have links or further explanations on
this topic?
Take the Scheme Report intro paragraph, for example:
"Programming languages should be designed not by piling feature on top
of feature, but by removing the weaknesses and restrictions that make
additional features appear necessary. Scheme demonstrates that a very
small number of rules for forming expressions, with no restrictions on
how they are composed, suffice to form a practical and efficient
programming language that is flexible enough to support most of the
major programming paradigms in use today. "
Contrast with a language such as VB in the context of MS COM:
http://www.roblocher.com/whitepapers/oletypes.aspx
I recall Allen mentioning mutable value types (!), multiple array and
date types, and a rising tide of non-compositional types and features.
If we make class-with-private-syntax bespoke and custom, we raise the
risk of creating some spec-internal new semantics (extending the ES5
kernel). Besides the loss of ability to mix-and-match functions and
objects using APIs, as Allen noted, all else equal the odds of loss of
compositionality go up.
You're right to stress, as Tom and Mark have from the start, that
private symbols must not pierce membranes (or else a side channel hazard
exists). That risk exists with bespoke (internal-weakmap-based)
private-in-class syntax and semantics too. There's no free lunch. Yes,
weak maps inside the spec avoid this hazard, but they could leak through
the spec abstraction -- and even if they don't, the lack of
property-in-object-named-by-private-symbol leaks.
We should stick to the minimize-kernel-semantics plan, and take the
Scheme Report's intro to heart.
/be
Thanks,
David
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
