public protected and private in javascript

[Struppi]

Aber es fehlen die grundlegendsten Dinge, echte private Member,

Äh, die sind doch im Funktionsscope geclosed und für innere Funktionen aber weiter verfügbar. Was anderes als das ist das Prinzip von "private"?

private ist in anderen Programmersprachen an die Klasse gebunden. Das was du meinst sind lokale Variabeln.

das sieht Crockford ua. anders.

Ja, das ist die Umsetzung von JS, aber nicht die Definition.

ja, es ist lokal, das Konzept gibt es in anderen Sprachen auch. Aber im Endeffekt drehst und windest du dich, ich weiß natürlich auch, dass man diese Paradigmen umsetzen könnte, sie sind aber einfach kein Bestandteil der Sprache.

Naja, ich verstehe wirklich nicht, was hier nicht umsetzbar ist, außer mit anderer Syntax und einem callback-Konzept.

Ich sage nicht, dass es nicht umsetzbar ist, aber es ist nicht bestandteil der Sprache. Und wenn du eine private Variabel - also eine Klassengebundene Variabel - definieren willst, musst du Umwege gehen, die wiederrum Fallstricke bergen. Denn wenn du im Konstruktor Funktionen an die Instanz anpappst, überschriebst du den prototypen. Zudem ist es umständlich zur Laufzeit die Funktionen zu definieren. Ausserdem bläht es die Konstruktorfunktion unnötig auf, es ist praktischer und schneller wenn du mit prototypen arbeitest, dann musst du aber auf private Klassenvariabeln verzichten

Du verwechselst hier was. Nochmal private heißt etwas ist an eine Klasse gebunden und der Zugriff ist nur innherhalb dieser Klasse erlaubt. lokale Variabeln sind lokale Variabeln die im scope einer Funktion (in Javascript) liegen.

Naja, s.o.. Die Seite bei Crockford heißt ja "private.html".

http://de.wikipedia.org/wiki/Objektorientierte_Programmierung#Methoden

"Private Methoden können nur von anderen Methoden derselben Klasse aufgerufen werden."

und das ist hier nicht der Fall, nur Funktionen die innerhalb des Konstruktors zur Laufzeit deklariert werden haben Zugriff.

protected heißt, dass in deinem Beispiel myExtendedObj Zugriff auf die Variabel myPrivate haben müßte, hat sie aber nicht

Ich sag doch Krücken gibt es immer, wie Florian schön und elegant, wie ich finde, mit seinem Code gezeigt hat.

Was ist das für eine "Krücke", wenn ich in einer Funktion definiere, was privat ist oder nicht bzw. bei der Übergabe einer callbackfunktion. Ich verstehe nur, dass das an anderer Stelle geschieht. Nicht aber, wie ein übergeordnetes Prinzip (Trennung von öffentlichen und privaten(=sicherheitsrelevanten oder den globalen Scope "verschmutzenden")  Variablen) hier nicht umsetzbar sein sollte. Allein die Syntax oder die Logik ist eine etwas andere.

Genau. Die Logik ist eine andere, darauf wollte ich hinaus.

Vielleicht macht es ja auch sinn mal nicht ganz allgemein über Vererbung zu reden sondern ganz konkret. Wieviel Vererbungen machen denn Sinn, und in welchen zusammenhängen?

Wenn du OO programmierst überall.

Naja, eben nicht. Es sei denn, man verwendet OO restriktiv bzw. synonym für "so wie in Java". S.a. das Zitat von Crockford "what can be more objectoriented than that".

Das ist seine Sichtweise, er betrachtet hier lediglich einen Teilaspekt - die prototypische Vererbung - da mag er Recht haben. Aber es ist eben nur ein Teilaspekt.

Eben weil es eben in JS nicht anders geht. Es ist aber nur eine Krücke und letztlich, wie gesagt, die einzige sinnvolle. In Sprachen die OO Regeln umsetzen, brauchst du diese nicht.

Naja, da beißt sich die Katze in den Schwanz. Macht ja auch nix. Immerhin lässt sich festhalten, dass namhafte und intelligente Menschen den Begriff OO anders fassen (Soshnikov und Crockford wie gesagt).

Keine Ahnung inweit diese als Experten für OOP gelten. Wenn es nur darum geht dass es Objekte gibt und das Verhalten irgendwie simuliert werden kann, dann dürfte jede Sprache ein OO Sprach sein.

Letztlich läßt sich das fehlen mancher Paradigmen nicht leugnen, sondern nur zeigen wie man über Umwege diese trotzdem erfüllt. Und das machen sie  gut.

Dann ist es ein closure, mit dem du solche ein Paradigma umsetzt. Oder man benutzt sowas wie Florian uns gezeigt hat. Dort ist das Prinzip wesentlich eleganter umgesetzt und du musst bei deinen Konstruktoren nicht alles Kapseln, sondern kannst diese recht lesbar gestalten. Leider mit den von mir genannnten Nachteilen.

Also die Lesbarkeit von YUI ist durchaus gegeben, würde ich auf den ersten Blick meinen (Stichwort JSON bzw. quasi-object literal).

Das hatte ich auch bereits gesagt. YUI ist sehr nah an JS und vereinfacht die Vererbung, ansonsten macht es nichts, was nötig wäre.

Struppi.