return Wert über JavaScript strukrur

[MB]

erfahrungsgemäß kann der Interpreter die foo instanzvariable b für bar nicht referrenzieren da er sie noch nicht kennt. Wenn sich bar zuerst hinschreibe geht das wiederum bei bar nicht.

funtion tok() {

  var foo = {
    b : bar
  }

  bar = {
    f : foo
  }
}

Frage 1: Wie kann man das unterbinden und trotzdem Scoping bewaren?

auch ist es mir ein rätsel wie der Interpreter mit den Blockanweisungen umgeht

var abc = function() {
  a();
  b();
  c();
}

Die funktion b() hat verschachtelte unterfuktionen die mit setInterval immer wieder rekursiv augerufen werden solang eine Bedingung in b() nicht erfüllt ist. Der Interpreter hat a(), c() und dann b() ausgeführt.

Frage 2: lag das vielleicht am setIntervall?

mfg MB

[Der Martin]

Hallo,

erfahrungsgemäß kann der Interpreter die foo instanzvariable b für bar nicht referrenzieren da er sie noch nicht kennt. Wenn sich bar zuerst hinschreibe geht das wiederum bei bar nicht.

funtion tok() {

  var foo = {
    b : bar
  }

  bar = {
    f : foo
  }
}

da hast du zwei Variablen, die sich gegenseitig referenzieren. Sozusagen ein Henne-Ei-Problem.

Frage 1: Wie kann man das unterbinden und trotzdem Scoping bewaren?

Indem man die Variablen zunächst nur deklariert, ihnen aber erst später ihre Werte zuweist:

funtion tok()
 { var foo = {}, bar = {};

   foo.b = bar;
   bar.f = foo;
 }

Ob das so wirklich sinnvoll ist, steht auf einem anderen Blatt. Und auch, ob man als Programmierer noch den Überblick behält, was nun Referenzen sind und was Kopien. Ich halte eine solche Struktur deshalb zumindest für heikel.

var abc = function() {
  a();
  b();
  c();
}

Die funktion b() hat verschachtelte unterfuktionen die mit setInterval immer wieder rekursiv augerufen werden solang eine Bedingung in b() nicht erfüllt ist. Der Interpreter hat a(), c() und dann b() ausgeführt.

Wie rekursiv? Wenn a(), b() und c() wirklich nur Funktionsaufrufe sind, die so nacheinander notiert sind, kann ich mir das nicht vorstellen. Die müssen eigentlich streng sequentiell, eine nach der anderen aufgerufen werden.

Frage 2: lag das vielleicht am setIntervall?

Ohne den genauen Code zu kennen, kann ich das nicht mit Sicherheit sagen, nur: Eventuell ja, aber ich kann mir im Moment noch nicht vorstellen, wie. Müsste man im Detail betrachten.

So long,
 Martin

[MB]

nabend Martin,

Ob das so wirklich sinnvoll ist, steht auf einem anderen Blatt. Und auch, ob man als Programmierer noch den Überblick behält, was nun Referenzen sind und was Kopien. Ich halte eine solche Struktur deshalb zumindest für heikel.

ok, danke für deine Bewertung.

Frage 2: lag das vielleicht am setIntervall?

Ohne den genauen Code zu kennen, kann ich das nicht mit Sicherheit sagen, nur: Eventuell ja, aber ich kann mir im Moment noch nicht vorstellen, wie. Müsste man im Detail betrachten.

Ok. Ich hab firebug verwendet. Der Interpreter verarbeitet denke ich wirklich a, b und c in reihenfolge. Aber die unterfunktionen von b, die sich immer wieder gegenseitig aufrufen, in der verarbeitung von abc() nur einmal. Nach der verarbeitung springt der wieder zu c(). Dann sind wieder die Untefunktionen von b() dran bis zum ende der for-schleife. Meine Überegungen - hoffe verständlich.

mfg MB

[JürgenB]

Hallo

Frage 2: lag das vielleicht am setIntervall?

Ohne den genauen Code zu kennen, kann ich das nicht mit Sicherheit sagen, nur: Eventuell ja, aber ich kann mir im Moment noch nicht vorstellen, wie. Müsste man im Detail betrachten.

Ok. Ich hab firebug verwendet. Der Interpreter verarbeitet denke ich wirklich a, b und c in reihenfolge. Aber die unterfunktionen von b, die sich immer wieder gegenseitig aufrufen, in der verarbeitung von abc() nur einmal. Nach der verarbeitung springt der wieder zu c(). Dann sind wieder die Untefunktionen von b() dran bis zum ende der for-schleife. Meine Überegungen - hoffe verständlich.

die Frage ist mit ja zu beantworten. Mit setIntervall oder setTimeout werden Teile des Scripts aus dem normalen Programmfluss genommen und zeitverzögert in die Taskschlange gestellt, sie laufen also frühestens erst dann, wenn der normale Programmfluss abgeschlossen ist. Die Browser unterstützen außer über Web Worker keinen Parallelbetrieb.

Gruß
Jürgen

[MB]

Hallo Jürgen

Frage 2: lag das vielleicht am setIntervall?

die Frage ist mit ja zu beantworten. Mit setIntervall oder setTimeout werden Teile des Scripts aus dem normalen Programmfluss genommen und zeitverzögert in die Taskschlange gestellt, sie laufen also frühestens erst dann, wenn der normale Programmfluss abgeschlossen ist. Die Browser unterstützen außer über Web Worker keinen Parallelbetrieb.

dannw äre das geklärt vielen Dank :-)

mfg MB

[Rolf b]

Hallo,

das Henne-Ei Problem ist eins, aber anders als formuliert (ich reite hier lediglich etwas auf Begrifflichkeiten rum). Javascript betreibt etwas, das Hoisting genannt wird. Das bedeutet, dass alle Deklarationen von Variablen automagisch an den Anfang der Funktion gezogen werden, in der sie vorkommen. Ein REFERENZIEREN von foo und bar ist also durchaus möglich. Die beiden folgenden Funktionen sind semantisch identisch:

function f1() 
{
   var foo = { b : bar },
       bar = { f : foo };
}
function f2() 
{
   var foo, bar;
   foo = { b : bar },
   bar = { f : foo };
}

Trotzdem funktioniert der Code nicht wie beabsichtigt, weil zwar die Deklaration gehoistet wird, aber an bar noch kein Wert zugewiesen ist, wenn foo.b erzeugt wird. Darum die Lösung Des Martin, weil sie erstmal leere Objekte anlegt, die dann bei der Erzeugung der Properties korrekt erreichbar sind.

Zur Sequentialität: Wenn ich eine Funktion dieser Art habe

var abc = function() {
   a();
   b();
   c();
}

dann wird während der Verarbeitung von abc() definitiv die Aufruffolge a, b, c eingehalten. Davon beißt die Maus keinen Faden ab (und bei Gunnar auch nicht die Tastatur). Sofern innerhalb von b per setTimeout oder setInterval ein zeitgesteuerter Aufruf von a, c oder auch b beauftragt wird, dann endet trotzdem ERST der Aufruf von abc(), und auch alle Aufrufe im Callstack, die dorthin geführt haben, bevor setTimeout oder setInterval zum Zug kommen.

Wenn Firebug diese Abfolge durcheinander bringt, dann ist der Firebug ein Stück Käse, an dem die Maus gern knabbern darf. Es ist zugegebenermaßen schwer für einen Debugger, solche Timingthemen exakt zu bewahren, aber im Fall von Javascript mit seiner strikt sequentiellen Verarbeitung (außer Webworker) ist das nicht soo schwer.

Jürgen, nur der Neugier halber - du schreibst dass die Browser Javascript strikt sequentiell abarbeiten. Hat bspw. Node oder eine andere Ausführungsumgebung andere Eigenschaften?

Gruß Rolf

[JürgenB]

Hallo,

Jürgen, nur der Neugier halber - du schreibst dass die Browser Javascript strikt sequentiell abarbeiten. Hat bspw. Node oder eine andere Ausführungsumgebung andere Eigenschaften?

ich kenne Javascript nur im Browser, zu „Node oder eine andere Ausführungsumgebung“ kann ich daher nichts sagen.

Gruß
Jürgen