Položil jste velmi dobrou otázku, a já jsem za ni rád. Přesně takovéhle dotazy obohacují článek. Nejprve ale odpovím na OT: Ano, ve druhém i třetím díle si ukážeme správné (i špatné) volání nejen parent konstruktoru, ale i libovolné jiné, třeba přepsané, metody.
Teď k těm privátním. Nerad bych předbíhal, ale potomek nikdy nezavolá privilegovanou metodu kterou, jak jsme si už řekli, používá Crockford k přístupu k privátním proměnným. Nezavolá, protože metoda začne existovat, až v okamžiku vytváření instance, čili, není součástí prototype. Museli bychom vždy povinně volat rodičovský konstruktor, nebo to nějak hacknout (že to lze prasácky nějak obejít, to nechci ani naznačovat ;)
Můžete namítnout: „A co když metoda sama bude privátní?“ To je případ, který záměrně ve výkladu nezmiňuji. Považuji jej totiž za zbytečný, náchylný k chybám, a svádějící k falešnému pocitu nějakého cool zabezpečení kódu. Je to relikt z ostatních jazyků, který dle mého jde proti duchu Javascriptu, a jehož použití je oprávněné pouze v příkladu s jQuery, microoptimalizací, a podobných vzácných případech. Přesto, jednu implementaci vám ukáži. Podívejte se na tento příklad, ale neberte si z něj příklad ;) http://jsfiddle.net/8EtRB/
Máme kvazi-privátní (ve skutečnosti lokální) metodu toString. Jestli je instanční, nebo statická, závisí na tom, jak metodu voláme. Takto definovaná metoda, může i využívat nějaké privátní statické proměnné, případně manipulovat přímo s instancí, pokud ji instanci předáme. Co je na tom příkladu tedy zlého? Za prvé, jedná se o zásadně jiný zápis. Zatímco v jazyce, který privátní členy podporuje klíčovým slovem private stačí použít klíčové slovo, zde musíme využít closure. Kód se bude hůře refaktorovat. Za druhé, tento zápis nejde změnit, což by nám později vadilo (v posledním díle si ukazujeme jak deklarovat s třídy nejen správně, ale i úsporně). Za třetí, a to je hlavní důvod, je to zcela zbytečné. Proč bych měl v jazyce jako je Javascript něco zapouzdřovat?
