Tach!

Äpfel und Birnen miteinander zu vergleichen ist nicht hilfreich, wenn Gleichheit das Ergebnis sein soll. Gäbe es denn für ES5 die Möglichkeit, das so umzusetzen, dass dein (wie mir scheint akademisches, aber was weiß ich schon) Beispiel das gewünschte Ergebnis liefert? Jedenfalls kann die aktuelle Versionen von Typescript auch nach ES6 übersetzen, dann ist das Ergebnis auch Code mit syntaktischen Zucker und die von dir angesprochenen Zusatzstoffe sind automatisch enthalten.

Es ging mir hier nicht um einen Vergleich von TypeScript und ECMAScript. Ich habe lediglich die Aussage von Christian aufgegriffen, wonach er eine von Array abgeleitete Klasse so ähnlich umgesetzt hätte wie in dem Code, zu dem das TypeScript-Beispiel übersetzt wurde. Jedenfalls habe ich ihn so verstanden, zumal er sich dabei auf meinen Beitrag bezogen hatte. Dementsprechend ging es mir nur darum zu zeigen, dass eine solche Implementierung nicht funktionieren kann.

Machst du gerade das "nicht funktionieren kann" an deinem einen Beispiel fest? Wenn ich dieses spezielle Möglichkeit nicht brauche, dann sehe ich ein völliges Funktionieren bezogen auf meine Anwendungsfälle (akademisch versus praktisch). Wenn ich mit Browsern / Javascript-Implementationen arbeiten muss, die ES5 aber noch kein ES6 können, dann ist es mir ziemlich egal, was das extends in ES6 noch so alles zusätzlich kann und dass das Typescript selbstverständlich nicht in der Lage ist, diese Features bieten zu können. Mir muss als Typescript-Benutzer klar sein, dass es nicht zaubern kann. Es gibt auch einige Sprachfeatures, die je nachdem, welches Target (ES5, ES6, ...) ich angebe, nicht zur Verfügung stehen (wie let bei ES5) oder die prinzipbedingt nur der Transpiler anmeckern kann, die aber, wenn ich oder andere Bibliotheken mit plain old Javascript weiterprogrammieren, umgangen werden (Zugriffsmodifikator private, starke Typisierung). Nichtsdestotrotz kann Typescript ein ziemlicher Gewinn für das Erstellen von Anwendungen sein. Vor allem auch dann, wenn man Features verwendet, die in der durch die Browser vorgegebenen, lediglich verwendbaren Javascript-Version ziemlich verbose zu implementieren sind, während Typescript eine verständliche Einzeilen-Syntax bietet (Getter/Setter).

Möglicherweise habe ich Christian aber auch falsch verstanden und er bezog sich nicht auf den konkreten Fall, der Gegenstand meiner Antwort an Felix war, sondern er meinte die Erstellung von abgeleiteten Klassen ganz allgemein. In diesem Fall wäre mein Beitrag vermutlich überflüssig.

Er sagte ja auch "ähnlich" und das enthält keinerlei Aussage darüber, ob bestimmte Features anderer Versionen von Javascript haarklein unterstützt werden oder vielleicht doch.

Der Ursprung der ganzen Diskussion liegt übrigens darin, dass ich, obwohl ich tatsächlich nur über akademisches Wissen verfüge und nicht auf zwanzig Jahre Entwicklertätigkeit zurückblicken kann, es dennoch für nötig befunden habe, in meinem Artikel der Frage nachzugehen, wie man eigene Methoden für Arrays definieren kann, ohne das Standardobjekt Array.prototype zu manipulieren,

Auf das Thema habe ich mich gar nicht bezogen. X Jahre Entwicklertätigkeit ist auch kein Argument, auf das ich einen Pfifferling geben würde, um daraus eine Aussage zur Qualität der Erzeugnisse oder gar des Wissens abzuleiten.

Dabei bin ich zu dem Ergebnis gekommen, dass die selbstdefinierten Methoden idealerweise auf einem prototypischen Objekt angelegt werden sollten, welches in der Prototypenkette zwischen den Arrays und dem Objekt Array.prototype einzufügen ist, sodass die Arrays sowohl die nativen Methoden, als auch die selbstdefinierten Methoden erben, ohne dass Array.prototype manipuliert wird und ohne die Methoden auf jeder einzelnen Instanz anlegen zu müssen, oder die Funktionalität anderswohin zu delegieren.

Am Ende muss das eigene Projekt gemäß der Aufgabenstellung arbeiten. Das was theoretisch alles möglich ist, braucht man meist alles gar nicht. Kein Kunde oder Anwender (wenn es kein geschäftlicher Auftrag war) schaut nach, wo man Standard-Objekte erweitert hat, wenn man sowas braucht oder ob man sich einfach ohne groß hinzuschauen das Polyfill aus dem MDN kopiert hat. Als Framework-Entwickler muss man auf Feinheiten der Sprache vermutlich eher achten als wenn man lediglich eine Anwendung für einen konkreten Zweck schreibt. Unwägbarkeiten wegen Browserimplementationen umgeht man, indem man mit einer konservativeren Herangehensweise weiterarbeitet.

Diese Lösung ist allerdings ohne die Syntax mit class und extends nicht zu verwirklichen, es sei denn, man fügt das prototypische Objekt mit den selbstdefinierten Methoden nach der Erzeugung der Instanzen in deren zu diesem Zeitpunkt bereits etablierte Prototypenkette ein, was aus Gründen der Performanz im Allgemeinen nicht zu empfehlen ist. Womit deine Frage wohl beantwortet wäre.

Also, das Feature geht sowieso nicht in ES5. Wenn ich das zufälligerweise brauchen würde, muss ich für das eigentliche Problem einen anderen Weg suchen, sodass sich die Notwendigkeit erübrigt. Nicht der Nachbau steht mir im Weg, sondern die für die praktische Anwendung generell nicht vorhandene Möglichkeit. Da muss man erst noch genügend Zeit ins Land streichen lassen, bevor man guten Gewissens die begrenzte Lauffähigkeit moderner Versionen auf alten Implementationen vernachlässigen kann. Wenn es dann soweit ist, steht man als Entwickler wieder an einem vergleichbaren Punkt. Die Sprache hat sich weiterentwickelt, die Implementation sind noch nicht völlig fertig und die Verbreitung moderner Browser nicht flächendeckend abgeschlossen (es sei denn, alle Nicht-Evergreen-Browser sind ausgestorben).

Nicht beantwortet ist damit aber die Frage, was denn nun als best practice für die Definition eigener Arraymethoden zu empfehlen sei. Hier bin ich zu dem Ergebnis gekommen, dass ich meinen Artikel nicht für die Leser von gestern, sondern für die Leser von morgen schreibe

Der Anwender von heute muss aber auch verwertbares Wissen im Wiki finden. Aber das scheinst du ja gemäß nachfolgenden, nicht mehr von mir zitierten Aussagen nicht unbeachtet zu lassen.

Weitere Lösungsmöglichkeiten fallen mir ehrlich gesagt nicht ein. Aber vielleicht müssen sie das ja auch nicht, weil das Problem rein akademisch ist. Womöglich habe ich beim Schreiben des Artikels und der Beiträge in diesem Thread einfach nur meine Zeit verschwendet, und die der Leser. Ob dem so ist, kann mir vielleicht jemand beantworten, der über mehr Praxiserfahrung verfügt als ich.

Es muss auch Leute geben, die Zeit haben, darüber nachzudenken, was theoretisch möglich ist. Der gehetzte Praktiker hingegen kopiert sich einen Polyfill oder umgeht das spezielle Problem mit einer alternativen Lösung für sein eigentliches Problem.

dedlfix.