On Monday, 2011-11-14 at 16:50 , 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 ES.next, 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!)
>
> > 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.
>
> > 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?
>
Some including me, want exemplars while others want classes. Good thing is that
with this proposal both of us will get what we want :)
>
> > 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.
>
> David
> > Allen
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected] (mailto:[email protected])
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
