<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Aug 9, 2011, at 10:23 AM, Bob Nystrom wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><br><br><div class="gmail_quote">On Mon, Aug 8, 2011 at 3:14 PM, Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com">allen@wirfs-brock.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word"><div><div>...</div></div></div></blockquote><div><br></div><div>I think it's reasonable to ask them to re-organize stuff a bit.</div>

<div><br></div><div>class A {</div><div>}</div><div><br></div><div>class B {</div><div>}</div><div><br></div><div>A.b = new B();</div><div>B.a = new A();</div><div><br></div><div>Do I understand the issue here, or am I missing some pieces?</div></div></blockquote><div><br></div><div>It sounds like you got it.</div><br><blockquote type="cite"><div class="gmail_quote">

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div>Yes, but by my rule above such a circularity would be an immediate name resolution error.  With class hoisting you have to actually analyze the inheritance chains to detect the error</div>

</div></div></blockquote><div><br></div><div>How does this play with modules? If I have two classes declared in different modules (which I assume will a common case, if not the most common) then hoisting or not hoisting won't help either way will it?</div></div></blockquote><div><br></div><div>Dave or Sam probably need to respond.  I haven't yet deeply internalized the semantics for mutually referential  modules in their proposal.  However, in general, I believe that such modules have to be processed as a unit and that would imply some implicit ordering of declarations.</div><div><br></div><blockquote type="cite"><div class="gmail_quote">

<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; position: static; z-index: auto; "><div style="word-wrap:break-word"><div><div class="im"><div>I still think the difference is likely to create confusion and I see no need to follow Java in this choice of keyword.  "subs" or "subclass"  might be a possibility. Or possibly:</div>

</div><div><div>   class superclass <| subclass () {</div><div>  }</div></div></div></div></blockquote><div><br></div></div></blockquote><div>I don't really like that either, but I do think there might be some merit to</div><div>  const subclass = class superclass <| () {/* your class body*/};</div><div>but that's for a different message.</div><br><blockquote type="cite"><div class="gmail_quote"><div>It would deeply astonish people to have the base class come <i>before</i> the derived class in a class declaration. I didn't even notice that's what you were doing the first few times I read that. C++, C#, Java, Ruby, Python, Ada, Dylan, CLOS, Eiffel, Objective-C, and Scala are all subclass-first.</div>

<div><br></div><div>Smalltalk and Self are superclass (or parent in the case of Self) first, but that's a syntactic side-effect because subclassing is just a message send and the receiver is on the left. That isn't the case with the syntax we're proposing here, which is a more Algol-style keyword-first form.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div style="word-wrap:break-word"><div><div class="im"><div><br></div></div><div>My main concern is baking time for getting more complex syntactic sugar (which, BTW, often ends up being more than just sugar) right.</div>

</div></div></blockquote><div><br></div><div>Baking time is a valid concern, and I think one we all share. The only solution I know of is to get the oven going as soon as we can.</div><div><br></div><div>I'm not personally as concerned about classes becoming more than syntactic sugar. JS already has the semantics needed to get something like classes working in a really friendly fashion, so adding new actual semantics would very likely overlap the existing ones in weird and nasty ways. Imagine trying to cram generic functions into Smalltalk while trying to retain the existing single-dispatch behavior too. </div></div></blockquote><div><br></div><div>Been there, WRT, multiple inheritance. It wasn't pretty. </div><div><br></div><blockquote type="cite"><div class="gmail_quote"><div>You'd end up with a strange chimera at best, and more likely just a stuffed jackalope.</div></div></blockquote><div><br></div><div>I think future proofing is also an argument for why we might want to go slow with a comprehensive class declaration syntax.  How confident are we that what we come up with would be suitable for adding multiple inheritance or traits/mix-ins or other plausible future extensions. We haven't even been able to agree on a  declarative property visibility syntax.  If we stop at the level of compositional class definition patterns like I have been proposing we have less risk of painting ourselves into a corner. </div><br><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>I think that alone will keep us honest. We <i>can't</i> jam in new dispatch semantics without making things really painful for ourselves.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div style="word-wrap:break-word"><div><div>The hoisting issues above are an example of the the sort of complexity that need to be worried about.  Simpler  constructors like <| and .{ are easier to get right and probably have lower long term impact if we get some detail wrong.</div>

</div></div></blockquote><div><br></div><div>Simpler constructs are easier to get right, but I think only because they push the hard work onto our users. If we <i>only</i> give them <| and .{, they'll have to come up with their own patterns to accomplish what they want in terms of those. Those patterns will be just as hard to get right as it would be for us to design a syntax directly in the language. The only difference is that instead of us doing that hard work once (and I'd like to hope we're the best-qualified to do it!), they'll re-invent it over and over again.</div></div></blockquote><div><br></div><div>But we shouldn't leave them to come up with their own patterns.  We (I'm now speaking about us more as individuals rather than as TC39) should document and evangelize the recommend compositional pattern for defining "classes" in "ES.next" </div><br><blockquote type="cite"><div class="gmail_quote">

<div><br></div><div>I definitely understand the desire to punt on this, but I think we'd do our users a disservice if we did. I believe we <i>can</i> design a good declarative syntax for this and that if we do so, we'll make ES a language that's easier to read and easier to use.</div>

</div></blockquote><br></div><div>Sure, we just have the normal schedule and complexity trade-offs that occur in any significant software project.  I'm not saying that you shouldn't push on this.  I'm more saying that it might not be a disaster if in the end it didn't make the cut, as long as we have the more compositional primitive (<|, super, private names, etc.) that allow synthesis of class-like abstraction patterns. I think it would be a bigger problem to not have those for ES.next.</div><div><br></div><div>Allen</div><br></body></html>