Alternative syntax for <|

David Flanagan dflanagan at mozilla.com
Thu Nov 17 12:06:09 PST 2011


On 11/16/11 11:45 AM, Erik Arvidsson wrote:
> Sorry for being too brief. Today the following works.
>
> f();
> ...
> function f() { ... }
>
> but the following does not:
>
> f();
> ...
> let f = function f() {};
>
> I think it is important that we keep the forward reference behavior
> with classes. This requires a declarative way of defining classes.
>
I agree with Erik and Dave that forward references are critical for 
classes.  If we define syntax for classes that is less foward-reference 
friendly than functions are, it will be a source of bugs (speaking from 
personal experience) and be perceived as a step backward.

A declarative syntax for defining classes is the goal of the classes 
proposal that *has already been accepted* into the harmony namespace 
http://wiki.ecmascript.org/doku.php?id=harmony:classes

> ECMAScript already has excellent features for defining abstractions 
> for kinds of things. The trinity of constructor functions, prototypes, 
> and instances are more than adequate for solving the problems that 
> classes solve in other languages. The intent of this strawman is not 
> to change those semantics. Instead, it's to provide a /terse/ and 
> /declarative/ surface for those semantics so that /programmer intent/ 
> is expressed instead of the /underlying imperative machinery/. 
But back to the topic of forward references, note that with today's 
class pattern of defining a constructor function and then initializing 
its prototype properties, we can write forward references to the 
constructor, and we can often invoke the constructor through a forward 
reference, but we can't invoke any methods on the initialized instances 
until the prototype object is actually initialized.  So forward 
references are only partially possible today.  A declarative class 
syntax that initializes the prototype as part of the hoisting process 
would be nice, though of course forward references from a prototype to 
another class will be tricky.

Also, today, in the absence of modules, some programmers give up the 
ability to use forward references in order to define their classes in a 
private scope:

     let Class = (function() { function C() {...}; C.prototype = {...}; 
return C; }());

I'm not familiar enough with the ES.next modules proposal to know what 
impact it has on forward references...

     David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111117/acf1f285/attachment-0001.html>


More information about the es-discuss mailing list