self-executing functions

So, ich hab jetzt Bahnhof - habe in der Zwischenzeit mal eben quer gelesen. Nun behauptet wer an anderer Stelle, dass die Problematik mit dem bspw. fehlenden Semikolon (hier im Thread erwähnt) mittels void function() { /* ... */ }() aus der Welt wäre. Nur:

Code: 
(function(){ /* code */ }()); // Crockford recommends this one
(function(){ /* code */ })(); // But this one works just as well

Täusche ich mich oder sind das die beiden Schreibweisen des TO? Allerdings schreibt der Autor, dass die beiden funktionieren ... wie man sieht.

Randnotiz: Ich habe gerade was von "labels" in einer function gelesen - das fand ich interessant, da sich diese Teile einer function bei Bedarf "skippen" lassen, die Funktion in der Folge aber noch weiter ausgeführt wird. Gibt ja schon interessante Dinge ... :)

Danke für den Hinweis mit dem alert() - ich mache eindeutig noch zu viel manuell. :D

Ich mische mich auch nicht weiter hier ein - da dürftet ihr gedanklich deutlich weiter sein.
 
SteelWheel schrieb:
Täusche ich mich oder sind das die beiden Schreibweisen des TO? Allerdings schreibt der Autor, dass die beiden funktionieren ... wie man sieht.
Zum Vergrößern anklicken....
solange aus der definition eine expression wird, ist die Klammersetzung (hier) egal. wie allerdings weiter oben schon gezeigt, gibt es noch andere Möglichkeiten diese Konversion zu erzwingen.

SteelWheel schrieb:
Randnotiz: Ich habe gerade was von "labels" in einer function gelesen - das fand ich interessant, da sich diese Teile einer function bei Bedarf "skippen" lassen, die Funktion in der Folge aber noch weiter ausgeführt wird. Gibt ja schon interessante Dinge ...
Zum Vergrößern anklicken....
labels sind nix Funktions-spezifisches, die kannst du überall einsetzen.
 
Dormilich schrieb:
was hat eine call expression damit zu tun? ich kann hier nur auf basis des script-codes argumentieren (wo es eine call expression gar nicht gibt), nicht auf basis des dahinterstehenden Compilers.
Zum Vergrößern anklicken....
hä? wir reden doch über js syntax, richtig? laut js syntax
ECMAScript Language Specification - ECMA-262 Edition 5.1
besteht ein programm aus statements und function declarations
function declarations ist denke ich klar, machen wir mit den statements weiter
ECMAScript Language Specification - ECMA-262 Edition 5.1
ein statement kann unter anderem ein expression statement sein
ECMAScript Language Specification - ECMA-262 Edition 5.1
welches eine expression ist.
ECMAScript Language Specification - ECMA-262 Edition 5.1
zu den expressions gehört die
ECMAScript Language Specification - ECMA-262 Edition 5.1
call expression welche eine member expression mit (argumenten) ist
zu den member expressions gehört die function expression

also ist laut syntaxbaum das
Code: 
function(value){
  console.log(value);
}(2);
eindeutig eine callexpression
da laut syntax ECMAScript Language Specification - ECMA-262 Edition 5.1 aber eine function declaration und eine function expression nicht auseinander gehalten werden können und es so zu konflikten kommen kann haben sie das so ECMAScript Language Specification - ECMA-262 Edition 5.1 gelöst
an ExpressionStatement cannot start with the function keyword because that might make it ambiguous with a FunctionDeclaration.
Zum Vergrößern anklicken....
und man muss den umweg über eine (sinnlose) primary expression gehen

- - - Aktualisiert - - -

SteelWheel schrieb:
Täusche ich mich oder sind das die beiden Schreibweisen des TO? Allerdings schreibt der Autor, dass die beiden funktionieren ... wie man sieht.
Zum Vergrößern anklicken....
ja, darum geht es doch, es gehen noch viel mehr
Code: 
++function(){ /* code */ }();
!function(){ /* code */ }();
man muss nur aus der function expression eine primary expression machen
 
j-l-n schrieb:
Und kann man jetzt sagen, was die beste Methode davon ist, oder ist das völlig egal? Denn warum ?
Zum Vergrößern anklicken....
bis auf besagte sache mit mehreren dateien die zusammengefasst werden UND eine am ende kein semikolon hat UND die folgende solch ein konstrukt verwendet ist es egal.
für den fall dass das doch von bedeutung sein sollte, erzeugt
datei n: alert(2)
datei n+1: (function(){;})()
und auch
datei n: alert(2)
datei n+1: (function(){;}())
einen laufzeitfehler
etwas wie
datei n: alert(2)
datei n+1: !function(){;}()
einen syntaxfehler den man schneller findet
 
ES6 (zirka Mitte 2015?) bringt ja ein paar schöööne Dinge mit ... na hoppla! let, classes, subclasses, for-of Loop ... .findIndex(), .assign() ... oder gar eine "promises"-API.

Das sieht ja alles ziemlich interessant aus - die Browser sind wohl auch schon schönes Stück vorwärts damit.

Hehe ... komme mir gerade so vor, als wäre ich irgendwie die letzten Jahre auf einem anderen Planeten gewesen. Man, ist mein JavaScript oldschool. :D Sollte in meine Signatur "Retro-Coder" aufnehmen.


Zurück zum Thema ... in meine kleine Verständniswelt, voll mit Eselsbrücken!

Also mir ist das noch nie (!) "in the wild" über den Weg gelaufen. Entweder lese ich weniger Quellcode als ich dachte, oder es ist wirklich nicht so weit verbreitet.

If you don't care about the return value, or the possibility of making your code slightly harder to read, you can save a byte by just prefixing the function with a unary operator.
Code: 
!function(){ /* code */ }();
~function(){ /* code */ }();
-function(){ /* code */ }();
+function(){ /* code */ }();
Zum Vergrößern anklicken....

Das ist dann nur eine andere (!; aber jeweils gleichbedeutende) Schreibweise für (function(){ ... })();? Ansonsten schule ich echt um auf "Zuhälter", "Drogenbaron" oder "Politiker" (ziemlich für alle die gleiche Stellenbeschreibung) ... ! Falls ich das (dann doch) verstanden haben sollte, erinnert mich das an Mandarin: 12 verschiedene Schreibweisen für das exakt gleiche Wort ... ! :rolleyes:

Das passt - IMO - auf eure Diskussion: "The most widely accepted way to tell the parser to expect a function expression is just to wrap it in parens, because in JavaScript, parens can’t contain statements. At this point, when the parser encounters the function keyword, it knows to parse it as a function expression and not a function declaration."

Randnotiz: Wenn ich das Beispiel von Dir, hesst, nehme, wäre void() zur Fehlerfindung aber durchaus Gift (um den Abbruch durch fehlendes ";" zu hindern) - vgl. mein letztes Posting. Hmmm ... !

Habt Dank für eure Geduld mit mir.
 
SteelWheel schrieb:
Das ist dann nur eine andere (!; aber jeweils gleichbedeutende) Schreibweise für (function(){ ... })();?
Zum Vergrößern anklicken....
ja, man wrappt die call expression mit einer primary expression

SteelWheel schrieb:
Randnotiz: Wenn ich das Beispiel von Dir, hesst, nehme, wäre void() zur Fehlerfindung aber durchaus Gift (um den Abbruch durch fehlendes ";" zu hindern) - vgl. mein letztes Posting.
Zum Vergrößern anklicken....
nein, void function() { /* ... */ }() verhält sich wie !function() { /* ... */ }()
 
void() wurde - wie erwähnt - empfohlen, um einem fehlenden ";" Herr zu werden, sofern im Anschluss noch so ein Konstrukt kommt.

Schade, doch keine Umschulung. :D
 
j-l-n schrieb:
Heutzutage völlig unrelevant
Zum Vergrößern anklicken....

Wie ich schon sagte: historisch eben ;-)

edit:
Frage mich aber ob es noch einen tieferliegenden Grund gibt... möglicherweise wegen der ursprünglichen Herkunft bzw. Anlehnung von Javascript an C. Muß mal recherchieren.

edit 2:
Brendan Eich schrieb:
Some have objected that this creates an unintended completion value leak-hazard, but (a) we can improve the Harmony definition of completion value in #-functions, (b) the void operator I added for javascript: URLs back in ’95 stands ready, and (c) when in doubt, use function syntax or write an explicit return.
Zum Vergrößern anklicken....
Genau für die href URLs hat er es rein genommen....
 
Zuletzt bearbeitet:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben