Lieber Reinhard,
Um das mal klarzustellen: Das Revealing Module Pattern ist in aller Regel mein Mittel der Wahl. In dieser Situation geht es aber darum, eine Klassen-API vernünftig zu gestalten.
hmm, bin mir nicht sicher, ob ich Dein Ansinnen so wirklich verstanden habe.
Hast du einen Blick auf mein (wenn auch sehr bescheidenes) Beispiel geworfen?
Ja.
Ich nutze ja das Revealing Module Pattern,
Das habe ich so direkt nicht darin erkannt, aber ich bin auch kein JavaScript-Wizard.
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).
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?
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. Das liegt sicherlich an meinen beschränkten Kenntnissen in JavaScript.
Nichtsdestotrotz, wenn die Verfügbarkeit von Symbol() nicht sicher ist, wären wir doch wieder bei meinem Ausgangsposting.
Ich würde die Helferfunktion in den Scope von myClass
packen. Da gehört es nach meinem Gefühl hin.
Liebe Grüße,
Felix Riesterer.