David Bruant wrote:
Le 20/01/2013 19:01, Brendan Eich a écrit :
David Bruant wrote:
Once again, the spec (well... you in that case :-) ) will do
whatever is necessary to make the feature understandable by spec
readers.
Transpilers will work with whatever is in the language. If they only
have weakmaps, they'll use that.
See http://wiki.ecmascript.org/doku.php?id=harmony:harmony, in
particular
Means
1.
Minimize the additional semantic state needed beyond ES5.
2.
Provide syntactic conveniences for:
1.
good abstraction patterns;
2.
high integrity patterns;
3.
defined by desugaring into kernel semantics.
We aim to unify the "spec problem" and the "transpiler problem" where
possible.
I think the goal of providing syntactic conveniences defined by
desugaring into kernel semantics is a valuable goal. It's good to
reason about this semantics and it's good for transpilers.
I however disagree that it should be taken to the letter as Allen
seems to take it. Specifically, I disagree with the idea that all
kernal semantics should be exposed as runtime constructs. They should
only if they prove to be useful for some other purpose.
Hence my "where possible".
Note the Reference internal type among others.
Please do try to avoid casting positions as absolute when they
explicitly are not.
Not always, not necessarily by spec-by-desugaring.
But we don't want magic in the spec that leaves transpilers falling
into the tarpit, if we can avoid it.
Semantics of private-class syntax hasn't been agreed on, so it's hard
to say if transpilers would have a hard time with the
eventually-agreed semantics, but Mark's desugaring with WeakMaps could
work, couldn't it?
Do we want protected? Do we have an issue (Kevin is getting at this)
with proxies observing that private-in-class is based on something other
than properties named by private symbols?
If proxies can observe that, yes, you are right: we may still use
internal spec types to specify private-in-class. But we should also
consider using weak maps and supporting transpilers, and committing to
any observables.
Doing so closes the door to private symbols in the future, in my view.
/be
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
