public protected and private in javascript

[molily]

Hallo,

Aber (tut mir Leid das ich jetzt auch noch mal auf
deinem Beispiel rumhacke molily) das war einfach mal das Paradebeispiel dafür warum ich die nativen Lösungen alle nicht allzu Prickelnd finde.

Es gibt keine »native Umsetzung«. Meine ist ebenso wenig wie deine »nativ«. Meine Helferfunktion macht exakt dasselbe wie du in der Zeile
_classConstructor.prototype = Object.create(_parentConstructor.prototype);

Ich muss ehrlicher weise zugeben das ich deinen Artikel noch nicht gelesen habe und somit deine inheritPseudoClass Funktion noch nicht kannte. Erst als ich mir die Implementierung agesehen habe wurde mir klar warum method4 nicht existiert.

Was soll das für ein Argument sein? APIs sind nicht selbsterklärend. Keine. Nicht jQuery, nicht PrototypeJS, nicht Mootools, nicht class.js. Wieso muss man bei class.js den Klassennamen als String übergeben, anstatt dass create sie zurückgibt? Wieso sind private, public, protected globale Variablen anstatt bspw. als Parameter in die Funktion gegeben zu werden? Das sind alles Entscheidungen für und gegen etwas. Sicher begründete, darum geht es nicht. Es sind einfach nicht triviale, nicht intuitive Entscheidungen, die man treffen muss.

Das Hauptproblem was ich bei nativen Umsetzung sehe ist, dass man Funktionen aufrufen muss nachdem man seine eigentliche Klassendefinition geschrieben hat, um die Logik seiner Klasse zu Komplettisieren.

Wie gesagt ist mir dieses Problem bekannt, aber relativ einfach lösbar. Es war schlicht nicht Anliegen des Artikels. Dort sollte nur dieses Pattern vorgestellt werden, welches sich so in fast allen Pseudoklassen-Implementationen findet.

Ich frage mich, was ihr alle habt. Bitte lest doch erst meinen Artikel und meine Postings hier. Ich habe nicht den Anspruch, mit einer zweizeiligen (!) Helfer-Funktion mit 200-zeiligen Klassenframeworks zu konkurrieren. Wie ich schon sagte, meine Lösung bietet wenig Komfort und wenig Flexibilität, sondern soll eine Kernaufgabe in eine Helferfunktion verlagern.

Es ist mehr eine Erklärung der internen Funktionsweise und der Hintergründe als eine robuste und in jedem Fall gebrauchstaugliche Lösung. Es ist gut, deren Beschränkungen aufzuzeigen (was mein Artikel auch bereits ansatzweise leisten soll), doch es bringt nichts, sie mit ausgereifteren Lösungen zu vergleichen.

So muss man beispielsweise den prototypen seine Klasse nachträglich setzen, oder sich irgendwo Methoden zwischen merken wenn man sie kurz darauf Überschreiben will, aber diese dennoch aufrufen will (super call).

Wie gesagt, wenn man den bestehenden Prototyp erhalten will und die Member in den neuen herüberretten will, kann man das mit ein paar Zeilen umsetzen.

Prototyping ist genial wenn man Funktionalitäten von Bibliotheken oder bestehenden Klassen erweitern will, aber sein Gundlogik so aufzubauen und zusammen zu halten ist jedoch sehr umständlich mit Prototyping.

Was meinst du mit Prototyping? Arbeitest du nicht mit prototypischer Vererbung?

Jetzt zu den bestehenden Frameworks. Ja durchaus gibt es ein Reihe von Frameworks mit den man ebenfalls seine Klassendefinitionen strukturiert verfassen kann. Aber auch hier habe ich noch keine Variante gefunden bei der man auf dem ersten Blick sieht wo was angegeben und deklariert wird.

Es gibt keine und wird auch keine geben. Wenn es die eine »richtige« Lösung gäbe, dann frage ich mich, warum sich sämtliche Pseudoklassen-Umsetzungen stark in der API unterscheiden.

var Chicken = Y.extend(...);
Wer mir hier auf Anhieb sagen kann was hier was zu bedeuten hat, verdient meinen Respekt.

Du verstehst ein Framework ganz alleine dadurch, dass du den Code liest, der die API nutzt? Du erkennst die Bedeutung von Parametern ganz intuitiv? Das halte ich für unmöglich. Sicher kann man eine API mehr oder weniger intuitiv gestalten. Die mir bekannten Pseudoklassen-APIs sind dazu jedoch zu komplex, als dass das alles selbsterklärend wäre.

Aber der kann mir sicherlich auch erklären warum die Argumentreihenfolge gerade Konstruktor, Elternkonstruktor und dann Members ist.

Ganz einfach: Sie ist willkürlich. So willkürlich wie Mootools alle Daten in einem Hash erwartet, so willkürlich wie PrototypeJS den Parent-Konstruktor bei Class.create als ersten Parameter entgegennimmt oder nur einen Hash-Parameter, wenn keine Superklasse existiert. Da sind alles für sich gesehen stimmige Entscheidungen - im Kontext des jeweiligen Frameworks und deren Paradigmen.

Nun über sein eigens Werk zu Urteilen ist immer schwer, aber wem schon einmal Klassen in einer typischen OO Programmiersprache über den Weg gelaufen sind, ...

Das ist, wie ich schon versucht habe darzulegen, eine problematische Überlegung, wenn es um JavaScript geht. Ich will dich nicht demotivieren, mache dein Framework ruhig breiter bekannt. Du wirst aber auch auf harsche Kritik von eingefleischten JavaScriptern stoßen. Leute, die JavaScript bewusst als JavaScript und nicht als Java programmieren und es für sinnvoll halten, dass Neueinsteiger JavaScript als solches lernen anstatt entscheidenden Sprachfeatures wegzukapseln. Leute, die durchaus kommerzielle JavaScript-Projekte mit zehntausenden Zeilen Code entwickeln und Frameworks einsetzen, die sehr strenge Strukturen vorgeben.

Neben Dojo und Ext JS ist YUI immer noch eins der größten und ausgereiftesten UI-Frameworks, an dem dutzende Entwickler parallel arbeiten. Es ist sicher nicht die Argumentreihenfolge von Y.extend, die für Erfolg oder Misserfolg verantwortlich ist. Wie gesagt bleibt YUI da vergleichsweise low-level, trotzdem benutzen m.W. sämtliche YUI-Module diese Struktur.

Hm hier schieden sich wohl die Geister warum muss der Programmierer sich selbst Strukturen schaffen?

Wenn das jeder tun würde und man mit mehreren Leuten an einem Projekt arbeitet, was gibt denn das für ein Wust...

Richtig, dafür gibt es Frameworks, die »Convention over Configuration« stellen. Dagegen habe ich nichts, im Gegenteil. Es gibt eben nur verschiedene mögliche Konventionen im Bereich Metaprogramming und Domain-specific Languages. Alle haben ihre Vorzüge und Anwendungsfälle. »Generisch« gibt es nicht, es ist immer eine bewusste Entscheidung für eine bestimmte Art, Probleme in Code auszudrücken, und damit gegen eine andere. Es gibt nicht umsonst neben statischen klassenbasierten Programmiersprachen viele andere. Diese sind nicht zwangsläufig chaotisch oder konventionslos und sollten deshalb in ein Klassenkorsett gezwängt werden, um sie brauchbar zu machen. Was Neueinsteiger angeht, so kann man sich nur auf eine Gruppe mit einem bestimmten Hintergrund kaprizieren, wie es dein Framework auch tut.

Mathias