class prototype object vs class instance properties

Brendan Eich brendan at
Sat Aug 18 14:36:39 PDT 2007

On Aug 18, 2007, at 1:51 PM, Garrett Smith wrote:

> But these methods are also bound, right?

Yes, good point -- I left out that further detail. |this| always  
refers in a method to the instance from which the method was called  
or extracted.

> In current coding conventions, many programmers (including myself)
> like to have the constructor's prototype assigment in one place with
> an object literal.

Yeah, I like and use that convention too.

> This "object literal"styleis not congruent to the prototype being a
> special instance (as in ES3 and 4 built-ins, with Date.prototype
> having value NaN, et c) . The above code style is clear and easy to
> read. You have the constructor, then the prototype.
> It would be nice to have a prototype block, like:
> class A {
>   init  : void =  function init()
>   prototype {
>   }

This is something proposed ages ago by Waldemar Horwat (then at  
Netscape) for ES4 -- any time you have

   prototype function m1(...) {...}
   prototype function m2(...) {...}
   prototype function m3(...) {...}

in some ES4 drafts waldemar wrote, you could instead say

   prototype {
     function m1(...) {...}
     function m2(...) {...}
     function m3(...) {...}

Waldemar's proposal allowed this for any kind of "attribute"  
qualifying a definition, including a namespace IIRC.

I'll bring this up at the next meeting, since you are quite right  
that the current builtins in the reference implementation are chatty.

> I am not sure if the with(prototype) { ... } would be suitable for
> that approach. I think with statements should not be encouraged.

Right, |with| is not suitable here -- it won't change the scope in  
which functions and vars are bound in a class any more than it would  
elsewhere (as it does not in ES1-3). Also, it is being deprecated  
(there's a reformed with that can be used if you're retrofitting, or  
if you like with and want to use it without scope ambiguity).

> I'm also confused on the syntax for function return type.
> ES4:
>>> class P { f:Void=  function  f()  {print('fff');}}
> [function Function]
>>> new P().f()
> [stack] []
> **ERROR** EvalError: uncaught exception: ReferenceError: unresolved
> object reference {multiname: [ns public '']::f } (near
> builtins/

You didn't define a method f in class P. Look:

 >> class P { f:Void=  function  f()  {print('fff');}}
[function Function]
 >> Void
[function Function]
 >> Void()

the f: is a section label, like private: or public:. The Void name is  
unbound and on the left-hand side of assignment (=) in class P's  
initialization code, so that's an assignment expression-statement  
executed once when the class is processed. Per the usual rules, the  
assignment binds a global property named 'Void'.

I don't know where you saw an example that looked anything like that.  
In the mail I wrote, to which you are replying here, I showed a void  

class C { function m():void {...} ...}

The return type annotation, which is optional, goes after the  
function formal parameter list, and starts with : as for all type  
annotations. The use of |void| here shows a special case: 'void' is  
not a type name, it means instead that the function cannot contain  
'return expr;' statements, only 'return;' statements and falling-off- 
the-end-without-return. There is no 'Void' type in ES4. The type of  
the undefined value is a type named undefined (available only in type  
expression contexts), same as for null/null.


More information about the Es4-discuss mailing list