Here are my rough notes for today's meeting.
Waldemar
--------------
Internationalization standard: Part of E262 or separate track? Pros
and cons to each one, and either would be workable. There is a
substantial area of interaction (ES5 locale methods, normalization,
and such) between them that will need to be addressed regardless of
which approach we take.
Lunch discussion over whether we want all locale-specific behavior
(examples: date formatting) to be implementation-defined or whether
we'd want to specify it for at least the major locales. Having
everything implementation-defined makes testing a hassle and will
result in different behavior on different platforms/browsers (as is
happening today). On the other hand, specifying the results for a lot
of locales is a lot of work.
Waldemar: Either would work. Personal preference is to make it part
of E262 if it's small (in terms of number of pages of standard) or
make it separate if it's large.
Agreed not to fast-track internationalization library (if it's a
separate standard) for now. It's going to be evolving too quickly.
Allen: Update on ISO fast track and ES5.1. Applause.
TC39 requested a vote on ES5.1 at the upcoming summer GA.
Allen: There's a significant community of users who are used to the
classical patterns of encapsulation (rather than using closures for
all encapsulation).
Waldemar and Dave: Important to be able to late-bind design decisions
and change them easily. This means that a programmer should be able
to relatively easily take code that uses a public object property and
refactor the code to make it private (or vice versa) without having to
restructure the code.
>From the mailing list discussions, we have, roughly speaking, two main
proposals:
A. Treat private properties like internal properties of objects.
Don't allow sticking private properties after the fact on unaware
objects such as frozen ones.
B. Treat private properties as syntactic sugar for weak maps. Allow
private properties on any object that works as a key for such a map.
Waldemar: B inherently supports strong encapsulation. A doesn't as
currently proposed due to its reflection API, but there is no inherent
reason why the reflection API needs to pierce privacy.
Discussion on role of reflection API, and what privileges you'd need
to use it. Java private fields may or may not be readable via the
reflection API depending on the security settings. Most of those seem
to fall under the category of being
debuggers/profilers/white-box-tests that can have special privileges.
MarkM, Waldemar: Prefer separate (unavailable without special
privileges) debugging API for reflecting on private properties.
Guards
Dave: This is abstract. Also, would rather do a general
user-extensible syntax for everything, which is perfectly doable as
part of the modules proposal.
Waldemar: Defining a general user-extensible syntax is far more
abstract and seems like a pie in the sky. Would want to see a solid
proposal before even considering such a thing.
In function type guards, should later guards be able to depend on the
values of earlier parameters? MarkM: No.
:: syntax seems fine.
Waldemar and MarkM will revive one of the past proposals.
Parameters property of functions
Doesn't interact well with code minimizers. Currently can extract
names of local parameters from a function's toString, but a number of
us like that this is difficult, as it discourages features that make
alpha-renaming refactoring difficult.
Allen prefers and wrote a mirror interface proposal on the same wiki page.
Briefly discussed relation to passing parameters by name. Brendan:
passing object literals is now simple enough that an extra feature for
passing parameters by name has little demand. Example:
function f({foo, bar}) {...}
f({foo, bar});
// Same as f({foo: foo, bar: bar})
Tails calls:
Waldemar concerned about interaction with guards, which would make
tails call no longer be tail calls.
What are the use cases? Not many, but they show up occasionally:
state machines, event handlers, etc.
Dave: Tail calls won't help with this kind of event soup:
XHR.get(x, #(y1) {
XHR.get(y, #(y2) {
XHR.get(z, #(y3) {
...
})
})
})
Moved tail calls into proposals. We'll need to check with
implementors to see how feasible this would be to implement. It will
be an issue for Rhino.
/x modifier in regexp:
Waldemar: Comments would make the regexp syntax ambiguous. Without
comments, worried about having a mismatched / or mismatched \ escape
start interpreting a whole bunch of source code as the body of a
regexp. Currently that's stopped by the end of the line, just like a
mismatched quote can only cause mayhem until the end of the line.
Alternatives are to do line continuations by using \<newline> or have
a different character sequence to introduce a multiline regexp.
Brendan:
#/ ...
// this is a comment
/* an so is this
*/
/#g
Discussed whether
#/ ... //comment /#
should be ok. Waldemar: yes, it should, because it falls out of the
two-phase process that we use to first find the end of the token and
then send the body to:
new RegExp(" ... //comment ", "#")
White space in a character class is not elided.
/y modifier in regexp: OK
JSON path:
Waldemar: Is there a way to follow a path using regular ES operators
rather than just path strings? This has powerful operators such as
tree and range searching, so it will tempt people to do the path
equivalent of eval("x." + field) where they want to do x[field].
What is the grammar for expressions in path strings? Is it the full
ECMAScript eval grammar plus things like the @ and $ operators?
MarkM: Quasiquote syntax example
Waldemar: Quasiquote syntax doesn't work well here because JSON path
expressions can have various free variables ($, @, etc.) that are
instantiated by the search.
XPath structures are trees, but here the ECMAScript objects being
queried can contain arbitrary graphs.
Object.isObject:
MarkM, Waldemar, Erik: Pleasantly surprised by Brendan's bold
alternative to fix typeof null to be "null". Very much in favor of
it.
How to write transitory code that works in both Harmony and ES5? Not
hard. Just need to consider both cases.
Transition to chatting about Harmony and code harmonizers:
A tangent: Allen: We have a discrepancy between function identifier
binding in function expressions vs. function statements. In function
expressions the body can reliably use it to recurse, while in a
function statement it could have been rebound by the time the function
runs.
Brendan: Never heard anybody complain about this.
MarkM: If we're making a harmonizer, let's get rid of semicolon
insertion as well.
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
