Classes: suggestions for improvement

Allen Wirfs-Brock allen at
Tue Jun 14 14:55:56 PDT 2011

On Jun 14, 2011, at 1:34 PM, felix wrote:

> On Tue, Jun 14, 2011 at 13:21, Bob Nystrom <rnystrom at> wrote:
>> On Tue, Jun 14, 2011 at 1:05 PM, felix <felix8a at> wrote:
>>> How about using "prototype" or "proto" as the keyword instead of "class"?
>>> It's a declaration of a prototypical object used to generate other
>>> objects.
>>> "prototype" is already a familiar word to JS programmers; this is just
>>> extending its use into a new but similar context.
>>> "prototype" has a looser, more script-y feel than "class".
>>> "prototype" has less baggage than "class"; JS is likely to be the only
>>> prototypal-inheritance language that most programmers know.
>>> "proto Point { }" reads well in English, it's a proto-Point.
>> I think that's been considered before. My complaint with it is that Point
>> isn't a prototype. It's a constructor function whose .prototype property is
>> the prototype. In other words, the object bound to the name Point isn't the
>> prototypical point. It's a constructor/class-thing/type-object kind of
>> thing. It owns the Point prototype, but isn't it itself.
> Hm, by that argument "class" isn't a particularly good term either,
> since the thing created is not a class, it's a thing that generates
> objects that can be considered instances of a class.  Maybe something
> like "factory" would be a better term then?

There are many definitions of "class" but most of the better, non-langauge specific ones are similar to the Wikipedia definition which starts out "In object-oriented programming, a class is a construct that is used as a blueprint to create instances of the class...A class defines constituent members which enable class instances to have state and behavior...."

This certainly fits the current class proposal.  We have a language construct (the class definition) that defines the constituent  state and behavior members (properties) of class instances.  Beyond that, we see features within the normal range of variations that are common for languages that have a class construct.  We define (optionally) name a constructor function rather than a class object but that still fits the basic definition. The fact, that shared instance members are factored into a separate object (the prototype) is mostly an design detail of the language and doesn't impact the basic meaning of "class".

The "Run-time Representation" section of the same article is also relevant.  It says: "As a data type, a class is usually considered as a compile-time construct. A language may also support prototype or factory metaobjects that represent run-time information about classes, or even represent metadata that provides access to reflection facilities and ability to manipulate data structure formats at run-time. Many languages distinguish this kind of run-time type information about classes from a class on the basis that the information is not needed at run-time. Some dynamic languages do not make strict distinctions between run-time and compile-time constructs, and therefore may not distinguish between metaobjects and classes."

In the proposal, a class is a compile-time construct of the language, it really doesn't exist at runtime.  Instead  at runtime we have the constructor/prototype pair of objects that are used together to create instances of the class. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list