July TC39 meeting notes, day 2

Brendan Eich brendan at mozilla.org
Thu Aug 4 18:45:25 PDT 2011


On Aug 4, 2011, at 3:15 PM, Oliver Hunt wrote:

> On Aug 4, 2011, at 2:29 PM, Brendan Eich wrote:
>> 1. return allowed from constructor?
>> ...
>> Consensus is: RESOLVED, return disallowed from class constructor body.
> 
> What about return with no value -- there are cases where such early returns are useful, and you would not be allowed to specify your own value (eg. there's an implicit return of |this|).  Most class-oriented languages have this behaviour (C++, Java, C#, etc), those that don't support early returns, frequently don't support return-statements at all (eg. the various object-pascal dialects).

That is a good point, one I think someone raised at the meeting (my note-taking failed there). This resolution was about banning return expression; in constructors, but not banning return; used well to avoid tortured and over-indented control flow.

The grammar at http://wiki.ecmascript.org/doku.php?id=harmony:classes does not restrict Statement at all, currently. The return-the-result-of-an-expression restriction could be done grammatically but it is easier to do with semantics, prose in this case.


>> 3. private variable use-syntax
> 
> My 2c:  i've always felt a prefix should be required to access a globally scoped variable/property in general, but no doubt people would complain about that degree of verbosity.  That said I'm unsure why there's such a desire to avoid standard scoping rules of every other language (where the properties of |this| are implicitly in scope),

You must mean languages that have static typing.

We have covered this before:

https://mail.mozilla.org/pipermail/es-discuss/2011-June/015125.html
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015129.html
https://mail.mozilla.org/pipermail/es-discuss/2011-June/015196.html


> with a mechanism to disambiguate access to the global scope if necessary (As C++ does, although i'm not suggesting C++'s syntax).

Object != scope, the Harmony scoping model is lexical. Mutable instances with mutable prototypes violate lexical scope if injected into scope environments.

Even if you managed to put just the private names that were declared by the class as private instance variable names (we agreed to take out the syntax for this, for the moment), how would you know whether other.foo where foo was private in the class should be the private name object, or the string-equated 'foo'?

Think of Point with private x, y and an equals method. Another method has to access a plain old object with public property x. You can't try private and then public (won't be right for edge cases with both names mapped, possibly differently along the prototype chain; won't be efficient). Unlike languages with static type information about |this| and other parameters, in JS you need to say when you mean to access a private-name-keyed property.

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110804/fbc9d2ec/attachment.html>


More information about the es-discuss mailing list