setInterval mit function "pointer" und parameter

[steve]

Hallo zusammen

Ich hatte bisher nie die Musse mich wirklich in Javascript einzuarbeiten, dafür macht mir die Sprache einfach einen zu hässlichen Eindruck :)

Deswegen ists bei mir immer etwas Flickwerk und jetzt bin ich wieder mal auf der Suche nach der korrekten Syntax. Wie schreib ich dies, damits funzt?:

  
meineIntervalReferenz=window.setInterval( myFIFO[0][0]( myFIFO[0][2] ) ,myFIFO[0][1] )  

FIFO[x][i]: x - nummer in der fifo, i=0:referenz auf ne funktion, i=1 die invervalperiode, i=2 ein argument für die funktion

Merci!

[LX]

Hallo!

Ich hatte bisher nie die Musse mich wirklich in Javascript einzuarbeiten, dafür macht mir die Sprache einfach einen zu hässlichen Eindruck :)

Dabei ist sie in ihrer Flexibilität wunderschön und hat einen eigenen Garten verdient. Allerdings kann man in ihr häßlichen Code schreiben, etwa so:

meineIntervalReferenz=window.setInterval( myFIFO[0]0 ,myFIFO[0][1] )

  
Damit das "funzt", kapsele den Aufruf der Funktion myFIFO[0][0] in eine function(){}, also  
  
[code lang=javascript]meineIntervalReferenz=window.setInterval(function(){ myFIFO[0][0]( myFIFO[0][2] ) }, myFIFO[0][1]);  
  
Übrigens sind Objekte mit sprechenden Namen möglicherweise besser geeignet als ein Array mit nichtssagenden Zahlen, d.h. myFIFO[0].callback, ~.timeout, ~.value statt [0], [1] und [2]. Deine Scripte werden dadurch lesbarer.  
  
Gruß, LX

-- 
RFC 2324, Satz 7 (Sicherheit): Jeder, der zwischen meinem Kaffee und mir steht, gilt als unsicher.

[steve]

Allerdings kann man in ihr häßlichen Code schreiben, etwa so: (...)

Haha, nice one! :)

Übrigens sind Objekte mit sprechenden Namen möglicherweise besser geeignet als ein Array mit nichtssagenden Zahlen, d.h. myFIFO[0].callback, ~.timeout, ~.value statt [0], [1] und [2]. Deine Scripte werden dadurch lesbarer.

Da hast du natürlich recht, bei kleinen Scripten bin ich dafür aber jeweils zu faul :)

lg

[Cheatah]

Hi,

Ich hatte bisher nie die Musse mich wirklich in Javascript einzuarbeiten, dafür macht mir die Sprache einfach einen zu hässlichen Eindruck :)

nun ja, die Mona Lisa ist auch irgendwie unhübsch.

Deswegen ists bei mir immer etwas Flickwerk und jetzt bin ich wieder mal auf der Suche nach der korrekten Syntax. Wie schreib ich dies, damits funzt?:

Mit einer korrekten Syntax, die *zusätzlich* das Gewünschte ergibt.

meineIntervalReferenz=window.setInterval( myFIFO[0]0 ,myFIFO[0][1] )

  
Bitte keine Leerzeichen an die Klammern grenzen lassen, das sieht ja widerlich aus. Auch ansonsten scheinst Du Leerzeichen nach merkwürdigen Prinzipien zu verteilen - kein Wunder, dass Du JavaScript hässlich findest. Ich korrigiere:  
  
~~~javascript
  
var meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);  

So. Nun lautet die Frage: Liefert die *Ausführung* von myFIFO[0]0 eine Funktion zurück? Wenn ja, kann das Intervall schon sinnvoll bestückt sein. Andernfalls könnte es sein, dass Du einfach nur eine anonyme Funktion einsetzen möchtest.

Cheatah

[steve]

nun ja, die Mona Lisa ist auch irgendwie unhübsch.

Genau, warum so ein Aufhebens um die? Ausserdem lächelt sie doch gar nicht :)

Bitte keine Leerzeichen an die Klammern grenzen lassen, das sieht ja widerlich aus. Auch ansonsten scheinst Du Leerzeichen nach merkwürdigen Prinzipien zu verteilen -

Javascript stört sich aber nicht an Leerzeichen oder, nur du? Ich sage dir jetzt nämlich, dass ich deine Version zwar nich hässlich, aber dennoch suboptimal finde. Leerzeichen in den Klammern machen jedes Gebilde sofort viel besser leserlich - Mein ganz persönlicher Tipp für dich.

»»Kein Wunder dass du Javascript hässlich findest
Allein schon der "+" Operator allein ist da Argument genug. Und in dem Zusammenhang auch gleich allgemein die gesamte Typisierung

Andernfalls könnte es sein, dass Du einfach nur eine anonyme Funktion einsetzen möchtest.

Das versuch ich mal.

Gruss

[ChrisB]

Hi,

meineIntervalReferenz=window.setInterval( myFIFO[0][0]( myFIFO[0][2] ) ,myFIFO[0][1] )  
var meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);

Bitte keine Leerzeichen an die Klammern grenzen lassen, das sieht ja widerlich aus. Auch ansonsten scheinst Du Leerzeichen nach merkwürdigen Prinzipien zu verteilen -
Javascript stört sich aber nicht an Leerzeichen oder, nur du? Ich sage dir jetzt nämlich, dass ich deine Version zwar nich hässlich, aber dennoch suboptimal finde.

Also wenn ich die beiden Versionen vergleiche, finde ich deine unleserlicher.
Insb. deshalb, weil bei dir der Zusammenhang zwischen Funktionsbezeichner myFIFO[0][0] und Parameter myFIFO[0][2] schlechter erkennbar ist - es erfordert genaue(re)s Hinschauen, um zu erkennen, dass das zweite ein Parameter für ersteres sein soll.
„Scanne“ ich Cheatahs Version oberflächlich, sehe ich hingegen sehr schnell, dass die äußere Methode hier zwei Parameter übergeben bekommt.

Leerzeichen in den Klammern machen jedes Gebilde sofort viel besser leserlich

Das ist Ansichtssache. Ich teile deine Ansicht nicht.

MfG ChrisB

[steve]

Hi

Natürlich hab ich in der geposteten Version das Leerzeichne beim Komma sehr unschön gesetzt :)

Das ist Ansichtssache. Ich teile deine Ansicht nicht.

Grundsätzlich schon. Nur: Mehr Leerraum=Weniger Information auf gleichem Raum. Daraus folgt automatisch dass man sich besser zurecht findet ;)

Lg

[Der Martin]

Hallo,

Mehr Leerraum=Weniger Information auf gleichem Raum. Daraus folgt automatisch dass man sich besser zurecht findet ;)

nein, das ist ein Trugschluss. Das Hinzufügen von Leerraum allein macht Programmcode nicht übersichtlicher oder leichter lesbar. Das ist nur dann der Fall, wenn der zusätzliche Leerraum so eingesetzt wird, dass gedanklich oder semantisch zusammengehörende Teile visuell enger zusammenrücken und von anderen, logisch entfernteren Teilen getrennt erscheinen.

Beispiele:

(a)   meineIntervalReferenz=window.setInterval(myFIFO[0][0](myFIFO[0][2]),myFIFO[0][1]);

(b)   meineIntervalReferenz=window.setInterval( myFIFO [0] [0] ( myFIFO [0] [2]), myFIFO [0] [1] );

(c)   meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);

Beispiel (a) ist maximal komprimiert und auf den ersten Blick nicht leicht zu erfassen. Beispiel (b) ist aber, obwohl eine Menge Leerzeichen eingefügt sind, nicht wirklich besser lesbar. Erst Beispiel (c) zeigt eine m.E. logische Gliederung durch wenige gezielt eingesetzte Leerzeichen, die das Lesen und Erfassen erleichtert.

So long,
 Martin

[Kai345]

[latex]Mae  govannen![/latex]

(b)   meineIntervalReferenz=window.setInterval( myFIFO [0] [0] ( myFIFO [0] [2]), myFIFO [0] [1] );

(c)   meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);

Beispiel (a) ist maximal komprimiert und auf den ersten Blick nicht leicht zu erfassen. Beispiel (b) ist aber, obwohl eine Menge Leerzeichen eingefügt sind, nicht wirklich besser lesbar. Erst Beispiel (c) zeigt eine m.E. logische Gliederung durch wenige gezielt eingesetzte Leerzeichen, die das Lesen und Erfassen erleichtert.

Ja. Beispiel 2 ist einfach nur verwirrend, da der in mir eingebaute Parser erst einmal sortieren muß, was zu welchem Teil des Ausdrucks gehört.

Wenn man sehr stark auf übersichtlicheren Code Wert legt, wird man - ich bleibe hier mal bei den falschen Beispielen[1] von oben - ohnehin eher zu

meineIntervalReferenz = window.setInterval(  
    myFIFO[0][0](myFIFO[0][2]),  
    myFIFO[0][1]  
);

tendieren.

Stur lächeln und winken, Männer!
Kai

[1] außer, wenn myFIFO[0][0] eine Funktionsreferenz zurückgibt, dann stimmt es natürlich.

[molily]

Beispiele:

(a)   meineIntervalReferenz=window.setInterval(myFIFO[0][0](myFIFO[0][2]),myFIFO[0][1]);

(b)   meineIntervalReferenz=window.setInterval( myFIFO [0] [0] ( myFIFO [0] [2]), myFIFO [0] [1] );

(c)   meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);

Ihr diskutiert doch nicht ernsthaft über die Lesbarkeit von diesem Code?

Dann würde man wie gesagt woanders anfangen, nämlich diese Arrays abschaffen und vor allem ihre Wiederholung.

var task    = myFIFO[0],
    handler = task.handler,
    arg     = task.argument,
    period  = task.period;

setInterval(handler.curry(arg), period);

Ob man DABEI jetzt noch mehr Whitespace einfügt oder nicht, macht den Braten nicht fett.

Mathias

[Der Martin]

Hallo,

(a)   meineIntervalReferenz=window.setInterval(myFIFO[0][0](myFIFO[0][2]),myFIFO[0][1]);

(b)   meineIntervalReferenz=window.setInterval( myFIFO [0] [0] ( myFIFO [0] [2]), myFIFO [0] [1] );

(c)   meineIntervalReferenz = window.setInterval(myFIFO[0][0](myFIFO[0][2]), myFIFO[0][1]);

Ihr diskutiert doch nicht ernsthaft über die Lesbarkeit von diesem Code?

nein, das war nur das aktuell greifbare Beispiel. Mir ging es dabei nur um den Aspekt, dass die Lesbarkeit durch den überlegten Einsatz von Leerraum verbessert wird, aber nicht, wie steve meinte, durch beliebigen Einsatz von Leerzeichen.

Dann würde man wie gesagt woanders anfangen, nämlich diese Arrays abschaffen und vor allem ihre Wiederholung.

var task    = myFIFO[0],
    handler = task.handler,
    arg     = task.argument,
    period  = task.period;

Dass das eine erhebliche Verbesserung der Lesbarkeit und Verständlichkeit ergibt, will ich nicht bestreiten.

Ciao,
 Martin

[molily]

Kein Wunder dass du Javascript hässlich findest
Allein schon der "+" Operator allein ist da Argument genug. Und in dem Zusammenhang auch gleich allgemein die gesamte Typisierung

Typisierung, genauer gesamt Coercion, in JavaScript ist so gelöst, dass sie einem die meisten Aufgaben einfach macht. In 90% der Fälle funktioniert Coercion so wie gewünscht. Man merkt es sie nicht, aber sie findet statt und der Code tut das, was man erwartet. In den restlichen 10% der Fälle muss man z.T. höllisch aufpassen. Über die wird dann natürlich groß gezetert. Eine Möglichkeit, damit umzugehen, ist Coercion komplett zu vermeiden bzw. zu umgehen, indem man Operatoren wie === verwendet und ständig srenge Typunterscheidungen mit typeof usw. macht. Ich halte das für unnötig, es ist besser, das Verhalten von Operatoren und deren Coercion zu verstehen. Dann kann man 90% weiterhin gedankenlos (aber informiert) schreiben und bei den 10% bewusst Mehrdeutigkeiten vermeiden.

Siehe dazu
http://es5.github.com/#x11.9.3
http://javascriptweblog.wordpress.com/2011/02/07/truth-equality-and-javascript/
http://webreflection.blogspot.com/2010/10/javascript-coercion-demystified.html
http://jscoercion.qfox.nl/
http://bonsaiden.github.com/JavaScript-Garden/#types

Mathias

[Der Martin]

Hi,

Typisierung, genauer gesamt Coercion, in JavaScript ist so gelöst, [...] es ist besser, das Verhalten von Operatoren und deren Coercion zu verstehen. Dann kann man 90% weiterhin gedankenlos (aber informiert) schreiben und bei den 10% bewusst Mehrdeutigkeiten vermeiden.

am grundlegenden Prinzip von Javascript ändern wir nichts; man kann die lockere (fast nicht vorhandene) Typisierung mögen oder auch nicht. Das spielt aber keine Rolle. Tatsache ist, dass man damit gelegentlich auf die Nase fallen kann, wie du ja auch einräumst.

Ich bin jedenfalls mit Programmiersprachen wie Pascal und später C "groß geworden", bei denen der Datentyp sehr wichtig ist[1], und mir gefällt dieses Konzept insgesamt besser. Aber das ist, wie gesagt, Geschmackssache.

So long,
 Martin

[1] Und sogar in Assembler, ohne inhärente Typisierung, ist es wichtig, dass man sich der Datentypen bewusst ist, damit man die Rohdaten, mit denen man hantiert, richtig interpretiert.

[molily]

Das Problem von JavaScript ist weniger die dynamische Typisierung, also dass eine Variable keinen definierten Typ zur Compile-Zeit hat. Die haben andere Programmiersprachen auch, ohne so lax wie JavaScript zu sein (bspw. Python und Ruby). Klar, die kann man natürlich nicht mögen, statisch getypte Sprache haben sicher ihre Vorteile.

Problematisch kann vor allem die schwache Typisierung werden. Also die automatische Typumwandlung, wenn ein anderer Typ erwartet wird oder inkompatible Typen aufeinandertreffen - eben die Coercion.

Diese ist aber auch nicht völlig willkürlich, sondern folgt eigentlich sehr festen, klaren und einfachen Regeln. Man muss sie nur jeweils kennen.

Mathias

[ChrisB]

Hi,

Ich bin jedenfalls mit Programmiersprachen wie Pascal und später C "groß geworden", bei denen der Datentyp sehr wichtig ist[1], und mir gefällt dieses Konzept insgesamt besser. Aber das ist, wie gesagt, Geschmackssache.

Ja - meiner ist bspw. anders :-)

Ich finde es extrem lästig, wenn man ständig jeden Mist casten oder sonstige Verrenkungen machen muss.

MfG ChrisB

[Der Martin]

Hallo,

Ich bin jedenfalls mit Programmiersprachen wie Pascal und später C "groß geworden", bei denen der Datentyp sehr wichtig ist[1], und mir gefällt dieses Konzept insgesamt besser. Aber das ist, wie gesagt, Geschmackssache.
Ich finde es extrem lästig, wenn man ständig jeden Mist casten oder sonstige Verrenkungen machen muss.

das muss man normalerweise nur sehr selten, weil man ja selten absichtlich inkompatible Datentypen zwangsverheiratet. Daher ist es eine feine Sache, wenn der Compiler einen solchen Versuch mit einer Fehlermeldung quittiert. Nur wenn ich *wirklich* einen normalerweise inkompatiblen Typ verwenden will, aus welchem Grund auch immer, muss ich casten[1].

Die diversen verschieden "breiten" Integer-Typen sind ja aus gutem Grund zumindest zuweisungskompatibel, d.h. ich kann jederzeit ein int einsetzen, wo ein char erwartet wird (und umgekehrt). Beim impliziten cast auf den kleineren Typ gibt's normalerweise eine Warnung vom Compiler, weil signifikante Information verlorengehen könnte.

Und so ist die feste Typisierung und Typprüfung IMHO kein Hemmnis, sondern eher ein zusätzliches Hilfsmittel, das dazu beiträgt, logische Fehler zu vermeiden.

Ciao,
 Martin

[1] Bei Klassenhierarchien in C++ sieht es teilweise etwas anders aus, hier sind Casts auch bei korrekten Zuweisungen oder Operationen oft notwendig. Das wird mir dann auch lästig.

[Don P]

Hallo,

Ich finde es extrem lästig, wenn man ständig jeden Mist casten oder sonstige Verrenkungen machen muss.

Ja, so geht's mir auch.

das muss man normalerweise nur sehr selten, weil man ja selten absichtlich inkompatible Datentypen zwangsverheiratet.

Mir passiert das oft. Wenn man z.B. XML-Daten verarbeitet, so sind die ja erst einmal Strings, auch wenn es eigentlich Zahlen oder Kalenderdaten sein sollen. Wenn man dann noch mathematisch damit rechnen muss, wird's ätzemd mit der Typgenauigkeit.

Wenn man z.B. berechnen soll, in welchem Quartal ein Monat liegt, kann man in JavaScript einfach notieren:

var quartal = Math.ceil(myDate.getMonth / 3).

In C# etwa wäre myDate.Month vom Typ int, und durch 3 teilen geht damit nicht wirklich. Also muss man es erst zu decimal oder float casten, dann dividieren, die nächst höhere Ganzzahl berechnen (noch immer decimal) und schleißlich wieder zu int casten:

int quartal = Convert.ToInt32(Math.Ceiling(Convert.ToDecimal(myDate.Month) / 3));  

Daher ist es eine feine Sache, wenn der Compiler einen solchen Versuch mit einer Fehlermeldung quittiert.

Nö, daher ist es richtig nervig, wenn der Compiler jede Kleinigkeit mit einer Fehlermeldung quittiert, und im Fall von im Fall von int dividiert durch int gibt er nicht mal eine aus. Das Ergebnis ist wieder int, was man selten haben will.

Das Theater mit den Klasenhierarchien hast du ja schon erwähnt. Wehe, man übegibt die falsche Klasse als Parameter... schon gibt's Mecker :(

Gruß, Don P

[Der Martin]

Moin,

das muss man normalerweise nur sehr selten, weil man ja selten absichtlich inkompatible Datentypen zwangsverheiratet.
Mir passiert das oft. Wenn man z.B. XML-Daten verarbeitet, so sind die ja erst einmal Strings, auch wenn es eigentlich Zahlen oder Kalenderdaten sein sollen. Wenn man dann noch mathematisch damit rechnen muss, wird's ätzemd mit der Typgenauigkeit.

genau das ist ein Fall, wo ich die Unterscheidung z.B. zwischen Strings und numerischen Typen für absolut richtig halte.

Wenn man z.B. berechnen soll, in welchem Quartal ein Monat liegt, kann man in JavaScript einfach notieren:
var quartal = Math.ceil(myDate.getMonth / 3).

Ja und? In C doch auch (angenommen, month sei 0..11):

int quartal = month/3 +1; // +1 nur, wenn man quartal nicht ab 0 zählen möchte

Läuft month dagegen von 1..12, ändert sich nur wenig:

int quartal = (month-1)/3 +1;

In C# etwa wäre myDate.Month vom Typ int, und durch 3 teilen geht damit nicht wirklich.

Wieso nicht? Was macht C# da so essentiell anders? Ist die Integer-Division in C# nicht definiert?

Also muss man es erst zu decimal oder float casten, dann dividieren, die nächst höhere Ganzzahl berechnen (noch immer decimal) und schleißlich wieder zu int casten:

int quartal = Convert.ToInt32(Math.Ceiling(Convert.ToDecimal(myDate.Month) / 3));

Das ist umständlich - und ich glaube nicht, dass das notwendig ist.

Daher ist es eine feine Sache, wenn der Compiler einen solchen Versuch mit einer Fehlermeldung quittiert.
Nö, daher ist es richtig nervig, wenn der Compiler jede Kleinigkeit mit einer Fehlermeldung quittiert, und im Fall von im Fall von int dividiert durch int gibt er nicht mal eine aus.

Warum sollte er auch? Das ist doch eine ganz normale Operation.

Das Ergebnis ist wieder int, was man selten haben will.

Doch, sicher - genau das will ich in geschätzten 99% aller Fälle haben. In den seltenen Fällen, wo ich als Ergebnis einer Operation, bei der die Operanden int sind, ausnahmsweise mal float bekommen möchte, muss ich halt einen der Operanden vorher nach float casten.

Ciao,
 Martin

[Don P]

Hallo,

In C# etwa wäre myDate.Month vom Typ int, und durch 3 teilen geht damit nicht wirklich.

Wieso nicht? Was macht C# da so essentiell anders? Ist die Integer-Division in C# nicht definiert?

Doch, aber das Ergebnis ist Integer. Mit z.B. int a = 8; evaluiert der Ausdruck a/3 halt zu 2. Korrekt wäre 2,3333..., aber das ist kein Integer mehr, sondern decimal oder float.
Man müsste dann z.B. a/(float)3 notieren oder (float)a/3.

So gesehen könnte man ein Quartal also auch so ermitteln:
int quartal = (int)Math.Ceiling(myDate.Month / float(3));

Das sieht zwar einfacher aus als mit Convert.ToXXX(), aber die Typecasterei bleibt einem trotzdem nicht erspart.

Das ist umständlich - und ich glaube nicht, dass das notwendig ist.

Ist es aber. Eine sog. implizierte Kontertierung funktioniert nur, wenn der neue Datentyp den alten aufnehmen kann, also z.B. long (=int64) zu int (=int32).

im Fall von int dividiert durch int gibt er nicht mal eine [Fehlermeldung] aus.

Warum sollte er auch? Das ist doch eine ganz normale Operation.

Dass 8/3 == 2 gilt, findest du normal?

Das Ergebnis ist wieder int, was man selten haben will.

Doch, sicher - genau das will ich in geschätzten 99% aller Fälle haben. In den seltenen Fällen, wo ich als Ergebnis einer Operation, bei der die Operanden int sind, ausnahmsweise mal float bekommen möchte, muss ich halt einen der Operanden vorher nach float casten.

Ja, leider muss man dann halt casten. Das ist gerade das lästige im Vergleich zu JavaScript, wo man wirklich selten casten muss.

Es dürfte doch eher die Ausnahme sein, dass eine Interger-Division glatt aufgeht, jedenfalls im normalen Leben ;) Wo nimmst du denn die 99% her?
Wenn ein Compiler nicht einmal so etwas offensichtliches von selber "richtig" macht, was kann man dann erst bei komplizierten Aufgaben von ihm erwarten?

Die Typ-Fehlermeldungen heißen doch auf deutsch immer nur "Sag's mir, Programmierer, ich bin zu blöd." ;)

System.Convert.ToGrußFormel( "Don P" )

[Der Martin]

Hi,

Wieso nicht? Was macht C# da so essentiell anders? Ist die Integer-Division in C# nicht definiert?
Doch, aber das Ergebnis ist Integer.

natürlich, soll es ja auch. Bei einer Operation, deren Operanden alle Integer sind, erwarte ich auch als Ergebnis einen Integer-Typ. Oder anders gesagt: Wenn ich mich in einem Kontext bewege, in dem ein Ergebnis in float sinnvoll wäre, dann sind in der Regel auch die Operanden schon float.

im Fall von int dividiert durch int gibt er nicht mal eine [Fehlermeldung] aus.
Warum sollte er auch? Das ist doch eine ganz normale Operation.
Dass 8/3 == 2 gilt, findest du normal?

Wenn ich mit Integerwerten hantiere, ja. Dann ist das genau das erwartete und "richtige" Ergebnis. Das ist ja genau das, was ich weiter oben schon sagte: Ich möchte nicht, dass ein Compiler oder Interpreter automatisch den Datentyp wechselt, nur weil das *auch* sinnvoll sein könnte.

Es dürfte doch eher die Ausnahme sein, dass eine Interger-Division glatt aufgeht, jedenfalls im normalen Leben ;) Wo nimmst du denn die 99% her?

Aus der Tatsache, dass ich, wenn ich als Programmierer tätig bin, fast nie mit Fließkommazahlen zu tun habe, sondern mich immer nur im Bereich der Ganzzahlen bewege. Fast immer. Und dann ist es eher vorteilhaft, wenn mir die Division an sich schon nur den ganzzahligen Teil liefert, so dass ich nicht noch explizit runden oder abschneiden muss. So wie bei deinem Quartals-Beispiel: Was für einen Sinn ergäne es, wenn ich für Mai das Quartal 1.66667 bekäme? Nein, im Bereich der Integerzahlen erhalte ich, wenn ich auch das berüchtige ±1-Problem beachte, sofort das richtige Ergebnis 2. Nicht 1.66667, auch nicht 2.0, sondern einfach 2.
Die meisten meiner C-Projekte enthalten gar kein Floating-Point-Support.

Wenn ein Compiler nicht einmal so etwas offensichtliches von selber "richtig" macht, ...

Es *ist* doch für die Menge der Ganzzahlen richtig. ;-)

Die Typ-Fehlermeldungen heißen doch auf deutsch immer nur "Sag's mir, Programmierer, ich bin zu blöd." ;)

Ich habe sie bisher immer verstanden als: "Bist du sicher, dass das okay ist, was du da tust?" Und das bringt mich manchmal zum Nachdenken und der Erkenntnis, dass ich irgendwo in dem Ausdruck einen Denk- oder Tippfehler habe, manchmal entlockt es mir auch nur ein gelangweiltes "Aber klar doch".

Schönes Wochenende noch,
 Martin

[molily]

meineIntervalReferenz=window.setInterval( myFIFO[0]0 ,myFIFO[0][1] )

>   
> FIFO[x][i]: x - nummer in der fifo, i=0:referenz auf ne funktion, i=1 die invervalperiode, i=2 ein argument für die funktion  
  
Lange Antwort:  
  
Funktionen sind in JavaScript Objekte erster Klasse. JavaScript unterstützt Currying und Partial Application, womit eine Funktion erstellt wird, die eine andere mit vorbelegten Parametern aufruft. Das kannst du mit einer [eigenen curry-Methode](http://molily.de/weblog/closures-performance#classic-curry) machen oder mit [bind](http://es5.github.com/#x15.3.4.5) aus ECMAScript 5 tun.  
  
~~~javascript
var f = myFIFO[0][0], arg = myFIFO[0][2], period = myFIFO[0][1];  
// Mit curry  
setInterval(f.curry(arg), period);  
// Mit bind  
setInterval(f.bind(null, arg), period);

Kurze Antwort:

Erzeuge eine Funktion, welche myFIFO[0]0 beinhaltet, und übergib diese an setInterval. Das kannst du direkt mit einer namenlosen Function Expression tun:

setInterval(function () {  
   myFIFO[0][0]( myFIFO[0][2] );  
}, myFIFO[0][1]);

curry und bind machen letztlich dasselbe, nur zentralisiert in funktionaler Syntax.

Mathias