No subject

Fri Jan 14 21:41:09 PST 2011

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.


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.

#/ ...
  // this is a comment
  /* an so is this

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.


MarkM, Waldemar, Erik:  Pleasantly surprised by Brendan's bold
alternative to fix typeof null to be "null".  Very much in favor of

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
Brendan:  Never heard anybody complain about this.

MarkM:  If we're making a harmonizer, let's get rid of semicolon
insertion as well.

More information about the es-discuss mailing list