Hey,
Wovor hast du eigentlich Angst/Bedenken/wasauchimmer? Wenn du Javascript-Code für andere schreibst, läuft der außerhalb deines Einflussbereiches und ist obendrein auch nicht vor Manipulationen und Einblicken geschützt. Im "Notfall" kopiert man sich den Code, korrigiert das ungewünschte Verhalten heraus und los gehts, egal was der ursprüngliche Autor eigentlich beabsichtigt hat.
Das ist mir bewusst.
Offensichtlich hat der Code ja an der Stelle eine Schwachstelle, zumindest aus der Perspektive des individuellen Anwendungsfalls heraus gesehen. Warum sollte ich die nicht für meine Anwendungsfall anpassen (dürfen)?
Dagegen spräche an sich auch nichts.
Ich sehe aber keinen Sinn darin, Helferfunktionen u.ä. in der Klassenschnittstelle zu verankern. Eine Klasse sollte doch nur jene Eigenschaften/Methoden nach außen hin sichtbar machen, die direkt in Verbindung mit der Klasse selbst stehen, und nicht wahllos jedes Stück Code, auf das sie zurückgreift, denn dann kann ich auch ein ganz normales Objekt benutzen ({}
). Ich will schließlich eine Klasse erzeugen, mit der Funktionalität, die ich, als Autor, beabsichtigt habe, und keine Klasse, die zusätzlich dazu auch noch ein schweizer Taschenmesser ist, das zusätzlich zum eigentlichen Verhalten auch noch das und das und das bietet.
Wenn jemand (widererwartend) eine bestimmte Funktionalität in der Klassenschnittstelle haben will, kann er das gerne tun, wenn er das für sinnvoll hält, das ist seine Sache. Ich, als Autor, halte das aber gerade nicht für sinnvoll und würde das deswegen eigentlich vermeiden.
Wenn ich an Entwicklungsumgebungen denke, würde ich sagen, dass es auch komisch aussähe, wenn ich eine Methode angeboten bekäme, die nicht direkt dokumentiert ist (da eigentlich private). Ich meine, was sollte ich sagen? „Ignore this.“, „Just don't touch this.“, ...
Ich würde mir als Autor keine gesteigerten Gedanken über die Verhinderung unerwünschten Ausführens durch legitime Verwender machen (bei unerwünschten Ausnutzern sieht die Sachlage anders aus). Verhindern kann ich es sowieso nicht vollständig.
Also kann man sagen, dass du auch dafür wärst Symbol() zu benutzen?
Wobei dann noch die Frage wäre, in wie weit man Symbol() heute schon in produktivem Code benutzen kann? Und generell all die hübschen Sachen, die ES6 zu bieten hat?
Reinhard