Das interessiert die ECMAScript-Community

Neues aus der JavaScript-Welt: Persistierte Variablen für Funktionen in ECMAScript?
Keine Kommentare

Auf der Mailingliste ES-Discuss und in zahlreichen GitHub-Repositories gehen ständig neue Vorschläge für die Weiterentwicklung von JavaScript ein. Derzeit wird diskutiert, ob Variablen in Funktionen und Methoden künftig persistent gestaltbar sein sollen

Schaut man sich auf GitHub und der Mailingliste ES-Discuss um, gibt es unzählige Proposals für ECMAScript. Proposals, das sind Vorschläge für die Standardisierung von syntaktischen Varianten und Implementierungen von Funktionen in den Kern von JavaScript: dem Standard ECMAScript. Wer ein Proposal ins Netz stellt, zielt genau darauf ab und hofft, dass die eigene Idee in den offiziellen Standard aufgenommen werden könnten.

TC39 & ECMAScript: Der Prozess

Welche Ideen tatsächlich den Schritt in die Standardisierung schaffen, entscheiden aber nicht die Ideengeber. Ein Proposal bezeichnet eigentlich einen Vorschlag, der es in den Staging-Prozess des TC39 geschafft hat, also von dem technischen Komitee diskutiert wird, das über neue Features für ECMAScript entscheidet. Dafür muss der Vorschlag von einem Champion vertreten werden, der dem Komitee angehört. Und das ist zumeist nicht der Fall, wenn ein neues Proposal im Netz diskutiert wird.

Einen Überblick über alle Proposals, die diesen Schritt bereits geschafft haben, gibt das TC39 in seinem GitHub-Repository. Propoals der Stufe 0 wurden dem Komitee entweder noch nicht vorgestellt oder wurden für nicht reif für Stufe 1 befunden, aber auch nicht völlig abgelehnt.

Das interessiert die ES-Discuss-Community

Die Diskussionen um noch nicht dort aufgenommene Proposals zeigen aber, was die Community derzeit bewegt. Auch zeigt ein Blick auf die Proposals, an denen das TC39 derzeit arbeitet, dass nicht alle davon von Mitgliedern des Komitees eingebracht wurden. Die Community kann hier also mitwirken, gute Ideen haben eine Chance, es in den Prozess zu schaffen. Eine Idee, die in den letzten Tagen diskutiert wurde, ist die der persistierten Variablen für Funktionen und Methoden. Eingebracht wurde die Idee zuerst von Neek Sandhu im GitHub-Repository von TypeScript.

Die Idee hinter dem Proposal ist, dass laut Sandhu fast jede App Funktionen oder Methoden enthalte, die einen Zustand über mehrere Aufrufe hinweg beibehalten sollen. Dies würde derzeit mit Closures mit IIFEs oder Top-Level Variablen gelöst. beide Lösungen empfindet Sandhu als „hässlich“, wie dem Proposaltext zu entnehmen ist. Der unterbreitete Alternativvorschlag lautet wie folgt:

 
function foo(n) {
    // initialized on first call to foo, persists for subsequent calls
    persist let counter =  0;

    // this way JS engine won't have to recompile the pattern everytime
    persist const httpRE = /^https?/;

    counter++;
    return n * a;
}

Dies stelle eine Art syntaktischen Zucker für IIFEs dar und entspreche dieser Lösung:

 
letlet foo  foo == (()  (() =>=> {
	 { 	letlet counter  counter = 0
	return (n) => {
    	let a = 12
        counter++
        return  n * a
    }
})()

Der Vorschlag erregte schnell einige Aufmerksamkeit unter den Teilnehmern der Mailingliste, traf allerdings nicht nur auf Zustimmung: Jacob Pratt fragte beispielsweise nach, inwiefern Sandhus Idee sich von this unterscheide. Sandhu verwies als Antwort darauf, dass dies nicht so schön sei wie persistierte Variablen. Letztere würden außerdem die Verkapselung der Variablen innerhalb des Bodys einer Funkion ermöglichen.

Alternative Ideen: Die Diskussion auf ES-Discuss

Auch diesen Vorteil hält jedoch nicht jeder Diskussionsteilnehmer für relevant: Peter Jaszkowiak argumentiert, dass gerade die Tatsache, dass es sich nur um syntaktischen Zucker handele, nicht unbedingt für die Idee spreche. So sei kein Mehrwert hinsichtlich der Verständlichkeit, Flexibilität in der Programmierung oder Präzision des Codes erkennbar. Isiah Meadows schlug außerdem die folgenden vier Alternativen vor:

Break it into a separate module.
Create a class for the mess.
Create an object for the mess.
Some combination of the above.
Each of these helps mitigate the scoping issue, and some of them also help ease the caching issue by keeping the cache closer to where it’s used.

Weitere Diskussionsbeiträge können auf der Plattform ES-Discuss nachgelesen werden, auf der die Beiträge der Mailingliste thematisch sortiert gesammelt werden.

Wie geht es nun weiter? Für Sandhus Vorschlag hat sich bislang kein TC39 Champion gefunden. Zwar gibt es in der Diskussion auch Kommentatoren, die der Idee eher zustimmend gegenüber stehen, die Mehrheit äußerte sich jedoch eher kritisch. Das könnte sich ungünstig auf die Chancen der Idee auswirken, wirklich zum Proposal zu werden.

ECMAScript: Keine persistierten Variablen, aber Decorators

Das TC39 tritt in der kommenden Woche wieder zusammen. Vom 24. bis 26 Juli trifft sich das Komitee in Redmond, Gastgeber ist dieses Mal Microsoft. Komitee-Mitglieder, die ein Proposal auf eine höhere Stufe im Staging-Prozess setzen lassen möchten, mussten dies bis zum 14.7. anmelden. Auf der Agenda findet sich unter anderem das Proposal für die Einführung von Decorators in JavaScript, das für Stufe 3 vorgeschlagen wird. Proposals der Stufe 3 müssen so weit fertiggestellt sein, dass für die weitere Ausarbeitung Feedback aus der Implementierung gewonnen werden muss. Die Spezifikation muss grundsätzlich fertig gestellt sein: „Complete: all semantics, syntax and API are completed described“. Damit wären Decorators also so gut wie fertig gestellt. Ideen, die derzeit auf der Mailingliste zu ECMAScript diskutiert werden, sind hingegen noch weit davon entfernt, diesen Status zu erreichen.

Unsere Redaktion empfiehlt:

Relevante Beiträge

X
- Gib Deinen Standort ein -
- or -