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 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!)
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
Allen
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
