On Mon, Oct 31, 2011 at 4:27 PM, Allen Wirfs-Brock
<al...@wirfs-brock.com> wrote:
>
> On Oct 31, 2011, at 10:45 AM, John J Barton wrote:
>
> On Mon, Oct 31, 2011 at 10:01 AM, Brendan Eich <bren...@mozilla.com> wrote:
>
> On Oct 31, 2011, at 9:45 AM, John J Barton wrote:
>
> In my opinion for new syntax to support classical inheritance should 1)
> target beginners and 2) help avoid the need for F.prototype/new F() pattern
> for simple inheritance.
>
> John, I almost-completely agree with you (yay!), except for the |new F|
> objection. What's wrong with operator new for class instantiation?
>
> ...
>
> In class languages I say:
>
> class F something E withOverrides {}
>
> ...
>
> Immediately after this phase the class-based language pattern leads
> you to think you are accomplishing great things, but mostly you are
> focusing premature on abstraction details. But that critical phase
> from "given an object |E|" to declaring |F| provides a big advantage.
> I believe this is why devs gravitate to selfish and extends() models.
>
> John,
> I'm going to circle back to some of your other points in another message,
> but first I want to address your final point.
> You start in the 9:45 AM message talking about making classical inheritance
> simple. However, in the final sentence you mention selfish and extends() as
> the things that devs gravitate towards as a solution to that problem. But
> those are both (more or less) prototypal inheritance based designs. They
> aren't doing classical inheritance.
I guess you think I am being inconsistent, in asking for classical
then pointing to prototypical examples. There is a bit of truth to
your claim. Before your explanations on this thread I knew that
classes were vague inferior to prototypes, mainly because I wrote too
many and yet not enough singleton classes in Java. Now I have deeper
understanding of classes (and a lower opinion of classes). But the
only aspect of my opinion on classes that matters is that we need a
simple pattern for classes. I keep coming back to 'selfish' because it
provides a 'simple' solution to prototypical inheritance.
I don't think devs are trying to solve the "I want to do classical
inheritance" problem. Rather they are trying to write an app that
makes sense. From this point of view a confusing pattern for classical
inheritance won't be useful. The thread-intro proposal is in my
opinion confusing and I am citing as evidence our experience with "new
F()/F.prototype".
> We have talked quite a bit about how we could support very simple expression
> of prototypal inheritance...
> We have recently taken to calling this pattern "object exemplars". It is
> prototypal inheritance, almost exactly equivalent to what selfish does. If
> we could all be satisfied with this there would be no need for the ongoing
> debate.
I could be satisfied, but I know you are not satisfied since you have
offered the pattern at the top of the thread.
...
> Sometimes it sounds like what you are asking for is precisely what objects
> exemplars provide. But other times you say you want "classical
> inheritance". Which is it?
This thread is about your interesting and provocative model for
classical inheritance in the mode of JavaScript. I'm not advocating
for classical inheritance. Rather, I'm advocating for 'simple
classical inheritance' and if we can't have simple, let's not have
classical.
What I don't want is a "classical" inheritance syntax that perpetuates
the confusing "new F()/F.prototype" paradigm and also seems more
complex than a Java-like solution.
jjb
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
