class prototype object vs class instance properties

Garrett Smith dhtmlkitchen at
Sat Aug 18 13:51:49 PDT 2007

On 8/18/07, Brendan Eich <brendan at> wrote:
> On Aug 18, 2007, at 10:13 AM, Garrett wrote:
> > liorean wrote:
> >>> What would be the benefit of a class having a prototype over
> >>> 9instance
> >>> properties/methods?
> >>
> >> Prototype properties can be shadowed by instance properties without
> >> being changed, prototype properties are fallbacks if the instance
> >> property does not exist, and prototype properties are not part of the
> >> actual instance, so can be used as memory footprint reduction if one
> >> has lots of instances that don't need separate values for that
> >> instance property.
> >> --
> >
> > That's pretty much how es3 works, then.
> In fact the reference implementation at uses
> ES4 class definitions to create the built-in classes from ES1-3
> (Object, Date, etc.). A few fine points:
> In |dynamic class Object {...}|, the |dynamic| keyword is required if
> you want the class's instances, not just its prototype, to allow ad-
> hoc properties to be set on them. So indeed, |Object| is a dynamic
> class in the reference implementation.
I understand that.

> In |class C { var x; }; c = new C; c.x = 42| and |dynamic class D
> { prototype var x; }; d = new D; d.x = 42| both c and d wind up with
> an x property having value 42. But c.x is a "fixture" -- it can't be
> deleted, and if it has a type annotation, that type constraint can't
> be altered. Whereas d.x is just an ad-hoc property on a dynamic
> class's instance, which happens to shadow prototype var x, but has no
> type relation to that prototype property.
> A function definition inside a class C's body |class C { function m
> ():void {...} ...}| creates a method fixture named m, which has a
> function structural type |function (this:C):void| and which can't be
> deleted or overwritten.
> So classes, fields (var in class), and methods (function in class)
> respectively provide objects with private members where the instances
> cannot be extended, properties that can't be deleted or have their
> type annotations violated, and receiver-based method dispatch (again
> with existence and type guarantees). These can be emulated in ES3 in
> several ways, at some cost in clarity and runtime efficiency.
I understand that.

But these methods are also bound, right?

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

function A {
// instance props.
A.prototype = {
  Events : {
// Enum would be nice.
    "open" : "open"

  ,init : function init() {

This "objec tliteral"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 {


  function A () {



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

I'm also confused on the syntax for function return type.

>> 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

> /be


More information about the Es4-discuss mailing list