public protected and private in javascript

[Struppi]

Naja, würdest Du wenigstens zustimmen, dass Soshnikov das in diesem Kapitel anders sieht? ("ECMAScript is the object-oriented programming language with the prototype based implementation."). Und im folgenden redet er ja von der OOP-Implementation von ECMA-Script. Da ist von rudimentär nicht die Rede,

Prototype based model of OOP has a number of differences from the static class based paradigm.

Ich befürchte es gibt soviele Schattierungen, in Bezug was OOP bedeutet, dass man letztlich von jeder Sprache behaupten kann sie wäre OO - ich meine ich hätte auch schon die Aussage von Leuten gelesen, dass man auch in C OO schreiben könnte.

Ich finde das Schlüsselwort new() wäre eigentlich schon ein guter Hinweis. Mit new kannst du Instanzen erzeugen. Aber genau die obige Aussage ist das Problem, wenn du eine Vielzahl der Paradigmen, die ein Konzept ausmachen, nicht mehr erfüllen kannst, ist die Frage inweiweit das Konzept umgesetzt ist.

Aber wie schon einmal gesagt, man sollte die Möglichkeiten der Sprache nutzen und nicht irgendwelchen Paradigmen hinterherlaufen, dann klappt's auch mit JS.

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.

Ein private Member ist Klassenweit sichtbar, nicht nur im Konstruktor, dass ist genau das, was Florian mit seinem Code erreichen will.

Naja, vielleicht willst du die Variable ja aber auch nur innerhalb einer Funktion sehen und auf den Konstruktor ganz verzichten. So verstehe ich auch peterS.: "mit dem konsequenten verzicht auf konstruktoren fuer eigene objekttypen entfiele in JavaScript auch der irrglaube ueber  >>obj.prototype.constructor<< etwas ueber die natur von >>obj<< zu erfahren<<. sobald mehrfachvererbung ins spiel kommt, hilft auch >>obj instanceof MyConstructor<< nicht weiter." https://forum.selfhtml.org/?t=203423&m=1376347. Und wenn du deinen ganzen Code in einer selbsausführende Funktion packst, bleibt Dein ganzer Klumpatsch doch sowieso nach außen hin komplett privat. Und mir dünkt ja eher, dass man mit Javascript eigentlich viel privater ist als mit "private".

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.

Ich dachte jetzt, Privatheit entsteht, in dem Du Funktionen als Objekte erster Klasse behandelst, was bedeutet, dass Du Privatheit durch callback-Funktionen erzeugst. Die callback-Funktion entscheidet, was passiert. Alles darin ist privat. Die aufrufende Funktion "weiß" nichts über das, was im callback passiert. Wieviel privater solls denn noch sein?

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.

protected geht gar nicht mehr.

Hm, kommt das nicht wirklich darauf an, wo man die Variablen definiert?

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

... stattdessen aber protected. Ich kann keine privaten Variablen in Unterfunktionen nutzen so dass sie dann auch vererbbar sind? Das was Crockford priveligierte Funktionen nennt?

Nein. privilegierte Funktionen dürfen auf private Member zugreifen. Normalerweise heißt aber privilegiert, dass du einer anderen Klasse erlaubst auf die privaten member zu zugreifen.

Und dafür kann ich keine Funktion bauen? U.u. auch eine verschachtelte?

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

protected heißt dass du private Elemente vererben kannst. Das geht mit JS Bordmitteln gar nicht.

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.

Schon dein Beispielcode könnte einiges mehr an Objekte und Vererbung vertragen, wenn du diesen Konsequent OO umsetzen wollstest.

Naja, das ist ein Weg, um beim programmieren nicht selber durcheinander zu kommen, macht man in Linux ja auch, indem man ein "." voranstellt. "Vorsicht, nicht anpacken". Aber nach außen hin gibt es die Privatheit ja doch, würde ich nach wie vor meinen. Ich sehe diese Konvention mit dem "_" bei YUI aber auch.

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.

Die Frage ist doch eher, wozu dieser Schutz sinnvoll ist. Wenn zB. eh alles in einem Closure gekapselt ist?

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.

Struppi.