The class operator: a bridge between object and function exemplers

Allen Wirfs-Brock allen at
Mon Nov 14 17:17:45 PST 2011

On Nov 14, 2011, at 4:50 PM, David Flanagan wrote:

> On 11/14/11 4:16 PM, Allen Wirfs-Brock wrote:
>> On Nov 14, 2011, at 3:15 PM, David Flanagan wrote:
>>> I have a bad feeling about making 'new' work with both functions and object exemplars.  If we can have two different types of classes, we're going to end up using typeof on our class objects to figure out what kind of class they are.  If I've got a value C from a library and I think it is an object exemplar, but it is in fact a constructor function, then 'class C' is going to return Function rather than C itself...
>> Well, new'ing object exemplars has always been the central concept of our discussions about them.  Essentially it is the self style of object creation and arguably the way the prototypal instantiation is supposed to work.  It seems to be what people who really like prototypal inheritance really want to do.
> Apparently I wasn't paying attention to the early discussions about object exemplars.  I've heard the term used, but missed the point about changing the behavior of new.  It seems to me people who want to use self-style object creation can use Object.create() and people who want to use JavaScript-style object creation can use new like we've been doing for 15 years.  (Just today I wrote a blog post explaining why I'm hoping for classes in, and included, as part of my argument, the assertion that all the proposals on the table are just syntax sugar without new language semantics.  I was wrong about that, I guess!)

Object create doesn't do the job because it doesn't provide for calling an "initialize" methods (turns out to be a very important part of the self-style).

>> The "magic" of what I'm proposing is that you will rarely have to worry about whether a named object abstraction (call it Foo) you get from a library is an object exemplar or a function/class exemplar.  Without knowing you can say:
>>     new Foo(args)
> Maybe I'm overreacting, and new semantics can make this all just work.  But it seems like a major, major change to the language.

being able to apply new to a non-function object is an addition, not a change.  Up to this point, the feedback seems to have viewed it as a minor addition.

>> and it will work.  Without knowing you can do either :
>>     let subfoo = Foo<| {constructor() {}};
>> or
>>    let subfoo =  class Foo<| {constructor() {}} //note this parses as: class (Foo<| {... })
>> and things will work.  You can even say:
>>    let subfoo = Foo<| function() {}
>> and the right thinks happen.
>> To me, this seems like the essence of object-oreinted implementation encapsulation.  All a client of Foo needs to know is that Foo is an "exemplar" and hence it can be instantiated (via new) or specialized (via<|).  It is up to the implementor of Foo to decide how to best express its implementation.  They can even change their mind and clients shouldn't care.
> Do JavaScript programmers want exemplars or do they want classes?

They seem to be split.    Some vocally ask for better support for prototypal inheritance other vocally ask for classes.

I think what everybody is asking for is a better way to "created named object abstractions".  The term exemplar is just one that I introduced into the discussion to make it easier to talk about the different kinds of entities you might apply such names to.  In some language you name a "class declaration", in others you name a prototypal instance, in JS you have historically named a function. Exemplar was intended to be a generic for such "named object abstractions". An object exemplar is a self style prototype, a class exemplar is the sort of thing you find in languages llke Java.  A function exemplar is a JS constructor,

>> Finally, if you really need to know whether an exemplar is an object exemplar or a function exemplar then typeof Foo is Function seems like a fine way to test it.  (I'm really growing to like the is operator...)
>>> Object exemplars does not pave the cowpaths for classes: it creates a new path and just smears out the concept of a class into something more broad.  I fear it will create confusion rather than " provide a terse and declarative surface for those semantics so that programmer intent is expressed instead of the underlying imperative machinery."
>> I look at it from the perspective that we already have at least two cowpaths that meander across each other in ways that  make it hard to stay on either one. I'm optimistic that we pave them in such a way that we are really dealing so parallel lanes on the freeway (and this analogy just got totally out of hand).
> If I may continue the out-of-hand metaphor, I worry that we'll end up with a two lane freeway that is being repaved and has "Warning: abrupt edge!" signs because one lane is bumpy and 2 inches lower than the other lane.

certainly not the goal


More information about the es-discuss mailing list