WH: C++ doesn't allow this kind of bottom-up construction (can't initialize a subclass instance before the superclass instance is initialized), and use cases like this arise once in a while. The usual workaround is to pass through Options objects.

JM: (example of type ahead classes in FB code base -- see 2_Before.js and 3_Before.js in the above gist)

AWB: Will always come to a place where a problem can't be solved with your existing inheritance model and you'll simply need to refactor. It's not that inheritance has failed, just that the class heirarchy needs to be refactored.

JM/SM: Refactoring is the correct approach, but it can be idealistic in some scenarios. Imagine a TypeaheadBase class that has been subclassed 100s of times. It's not until the 101th time that you realize you need to refactor the base class (and, thus, all pre-existing subclasses)

Discussion about subclasses that require two phase construction (with instance side initialization methods)

Mixed discussion about allocation phases.

MM: Do we have consensus on the instantiation reform we agreed to yesterday?

yes.

[JM agrees on the grounds that there are at least legacy style workarounds for that 101th subclass and the rest of the patterns he found a la <<SuperClass>>.call()]

YK: will not be ok with this solution if it switches on the instantiation of the constructor

...Need help covering this...

WH: I insisted on having a syntactic switch for function-vs-generator rather than switching on the presence of a yield. The reason was that functions and generators are radically different and it makes sense for a trivial generator to have no yields. In this case I'd mildly prefer to have a syntactic switch as well, but it's not as crucial because I haven't seen any good examples of where apparently problem-free code would unexpectedly go wrong. If you don't call the superclass constructor, you'll miss out on superclass initialization, which would be a problem even if the presence of a super call didn't statically switch modes, so the mode switch hasn't created a problem where there wasn't one. Inserting or deleting an "if (false) super()" does change things, but I don't see why one would be likely to do that. [I suppose that you could stylistically mark inheriting constructors whose super() calls are deeply buried with an "if (false) super()" at the top :).]

MM: I agree there is a smell with super; would I adopt syntactic marking? I want to see them first.

WH: On the fence, suppose we do this, what if you call super in a method not marked? What does that do?

DH: It's ok for class body to have more syntactic distinctions than outside functions acting as constructor

AWB: You could imagine that I have a splat that indicates "I do not want allocation for this class"