Hey,
Ich nutze ja das Revealing Module Pattern,
Das habe ich so direkt nicht darin erkannt, aber ich bin auch kein JavaScript-Wizard.
IIFE in dem (u.a.) die Klasse myClass gekapselt ist?
aber ich frage mich, inwiefern die besagte
reverse
Methode sinnvoll ist.Mich stört, dass sie im selben Namensraum herumliegt, wie der Klassenname selbst. Ich hätte sie vom Scope her in die Klasse selbst verfrachtet (siehe mein Beispiel).
Das stört mich eigentlich nicht so sehr.
Ich würde die Helferfunktion in den Scope von
myClass
packen. Da gehört es nach meinem Gefühl hin.
Und genau da ist das Riesen-Problem: Die Helferfunktion soll von den API-Methoden aufgerufen werden, also den Methoden, die ich im Prototyp definiere. Und genau das geht so nicht. Im müsste diese Methoden jedes Mal neu als Eigenschaft einer Instanz definieren. Und das erscheint mir alles andere als toll.
Auf der einen Seite gehört sie insofern zur Klasse, als dass sie eine solche Klasse als Parameter (oder this-Kontext) erwartet, auf der anderen Seite ist es eine Helferfunktion und damit nicht als API-Methode gedacht.
Warum sollte diese Helferfunktion für andere Klassen erreichbar sein? Benötigen diese auch eine reverse-Methode?
Verstehe ich nicht. Die Helferfunktion(en) sind in meinem speziellen Fall nur für eine Klasse gedacht.
Symbol() würde, wie @1unitedpower angemerkt hat, die Helferfunktion als pseudo-private Methode in der API verfügbar machen, aber hätte einen engeren Kontext zur Klasse als wenn auf eine private Variable referenziert werden würde.
Inwiefern dieser engere Kontext tatsächlich nachvollziehbar ist, kann ich nicht beurteilen, da ich nicht verstanden habe, worauf Du wirklich hinaus willst.
Meine Frage zielt darauf ab herauszufinden, wohin man Funktionen schreiben sollte, die mit einer Klasse und ihren Eigenschaften arbeitet, die aber nicht direkt von außerhalb aufgerufen werden sollten (wohl aber von den Methoden im Prototyp), und wie diese aufgebaut sind (siehe reverse1/2
in meinem Ausgangsbeispiel).
Reinhard