Hallo Felix, das wird mir jetzt zu umfangreich, um viel dazu zu schreiben. Ist wohl auch nicht nötig, du hast Deine Ideen und sie sind anders als meine. Als Lehrer hast Du da professionelle Vorteile in der Wissensvermittlung. Als Programmierer habe ich vielleicht professionelle Vorteile in der Webentwicklung 😉. Und deine Vorteile sind für den Zweck die relevanteren. Ich habe auch nur die erste Seite deiner Texte gesehen. Irgendwie hat, als ich da vorher war, die Verlinkung zum nächsten Abschnitt nicht funktioniert. Jetzt ist es ok. Ich möchte nur auf einen deiner Punkte eingehen, und warte im übrigen ab, wie sich dein Tutorial entwickelt. Sagst Du Bescheid, wenn es fertig ist? > class - Wo sind die Fallstricke für den Programmierer, wenn er sich dabei der Prototypen-Kette nicht bewusst ist? Ich erinnere mich an meine ersten Gehversuche mit OOP. Borland C++, in den 80er Jahren. Ich habe ewig mit dem Debugger über den internen Abläufen gehangen, um zu verstehen, was da eigentlich passiert. Um zu begreifen, was virtuelle Methoden eigentlich sind. Ich möchte wissen, was unter der Haube passiert. Außer beim Auto. Da kapiere ich das eh nicht 😂 Wer auf hohem Abstraktionsniveau herumturnt, scheitert in dem Moment, wo das von der Abstraktion vorgegebene Modell seine Grenzen erreicht. Oder wo das Modell falsche Freunde vorzeigt - JS-OOP ist eben nicht Klassen-, sondern Prototypbasierend. Die class-Syntax simuliert eine klassenorientierte OOP, ist aber keine. Klassen werden zur Compilezeit definiert und sind zur Laufzeit unveränderlich. Verändert man einen Prototypen, wird das in allen Objekten sofort sichtbar, die ihn benutzen. Bei Prototypen spricht man aus gutem Grund von "klassenloser OOP". Ich bin mir im Moment keiner Fallstricke bewusst. Es mag aber welche geben, wenn man z.B. nicht weiß, dass die mit `this.wert = 17` erzeugten Eigenschaften am Objekt gespeichert sind, aber Methoden, getter und setter am Prototypen landen. Wenn Vererbung ins Spiel kommt, wird es noch subtiler. In einem Klassenkonstrukt kann ich Eigenschaftsdefinitionen in einer Subklasse überschreiben. Die Eigenschaft ist in der Subklasse aber nach wie vor vorhanden und kann - je nach Sprache - auch benutzt werden. In JS liegen alle Eigenschaften am Objekt. Wenn die Superklasse `this.foo=3;` setzt und die Subklasse danach `this.foo=7;`, dann ist das das gleiche `foo`. Methoden der Superklasse sehen danach die 7. In C++ könnte ich in der Subklasse das foo der Superklasse überlagern. PHP verhält sich unterschiedlich, je nach dem, ob die Eigenschaft in der Superklasse private ist oder nicht (ARGHH!). Es ist didaktisch vermutlich ganz elegant, mit der class-Syntax loszulegen. Aber irgendwann muss man auch an's Eingemachte und erklären, wie die Vererbung in JS tickt. Du hast schon recht, das kann man später tun. _Rolf_ -- sumpsi - posui - obstruxi

Hallo Felix, das wird mir jetzt zu umfangreich, um viel dazu zu schreiben. Ist wohl auch nicht nötig, du hast Deine Ideen und sie sind anders als meine. Als Lehrer hast Du da professionelle Vorteile in der Wissensvermittlung. Als Programmierer habe ich vielleicht professionelle Vorteile in der Webentwicklung 😉. Und deine Vorteile sind für den Zweck die relevanteren. Nur eins: > class - Wo sind die Fallstricke für den Programmierer, wenn er sich dabei der Prototypen-Kette nicht bewusst ist? Ich erinnere mich an meine ersten Gehversuche mit OOP. Borland C++, in den 80er Jahren. Ich habe ewig mit dem Debugger über den internen Abläufen gehangen, um zu verstehen, was da eigentlich passiert. Um zu begreifen, was virtuelle Methoden eigentlich sind. Ich möchte wissen, was unter der Haube passiert. Außer beim Auto. Da kapiere ich das eh nicht 😂 Wer auf hohem Abstraktionsniveau herumturnt, scheitert in dem Moment, wo das von der Abstraktion vorgegebene Modell seine Grenzen erreicht. Oder wo das Modell falsche Freunde vorzeigt - JS-OOP ist eben nicht Klassen-, sondern Prototypbasierend. Die class-Syntax simuliert eine klassenorientierte OOP, ist aber keine. Klassen werden zur Compilezeit definiert und sind zur Laufzeit unveränderlich. Verändert man einen Prototypen, wird das in allen Objekten sofort sichtbar, die ihn benutzen. Bei Prototypen spricht man aus gutem Grund von "klassenloser OOP". Ich bin mir im Moment keiner Fallstricke bewusst. Es mag aber welche geben, wenn man z.B. nicht weiß, dass die mit `this.wert = 17` erzeugten Eigenschaften am Objekt gespeichert sind, aber Methoden, getter und setter am Prototypen landen. Wenn Vererbung ins Spiel kommt, wird es noch subtiler. In einem Klassenkonstrukt kann ich Eigenschaftsdefinitionen in einer Subklasse überschreiben. Die Eigenschaft ist in der Subklasse aber nach wie vor vorhanden und kann - je nach Sprache - auch benutzt werden. In JS liegen alle Eigenschaften am Objekt. Wenn die Superklasse `this.foo=3;` setzt und die Subklasse danach `this.foo=7;`, dann ist das das gleiche `foo`. Methoden der Superklasse sehen danach die 7. In C++ könnte ich in der Subklasse das foo der Superklasse überlagern. PHP verhält sich unterschiedlich, je nach dem, ob die Eigenschaft in der Superklasse private ist oder nicht (ARGHH!). Es ist didaktisch vermutlich ganz elegant, mit der class-Syntax loszulegen. Aber irgendwann muss man auch an's Eingemachte und erklären, wie die Vererbung in JS tickt. Du hast schon recht, das kann man später tun. _Rolf_ -- sumpsi - posui - obstruxi