Reihenfolge von Listenelementen

[interpreter]

hallo,

bin ziemlich frisch in dem Forum und hatte mit AppleScript noch nicht viel zu tun, jedenfalls hat mich die Suche nicht weitergebracht, deshalb stell ich mal hier meine Frage:
Warum vertauscht Applescript die Reihenfolge von Listenelementen? Folgendes Beispiel ist mit xcode 1.5 geschrieben:

set test1 to {foo1:"foooo", foo2:"foooo2"}
set test2 to {bar1:"bar"}
set testcomplete to {eins:test1, zwei:test2}
log "PARAMS"
log testcomplete

bei der Ausführung sagt das Logfile aber:

2006-02-24 13:13:17.587  "PARAMS"
2006-02-24 13:13:17.599  {zwei:{bar1:"bar"}, eins:{foo1:"foooo", foo2:"foooo2"}}

Wieso werden die Elemente "eins" und "zwei" vertauscht, gibt es eine andere Möglichkeit bzw. anderen Datentyp für Listen ?

 

[Daisy]

Bist mir zuvorgekommen, Pete

Klar dass das egal ist, aber was schon komisch ist: Probier' das mal im Skripteditor aus - da ist die Reihenfolge richtig

Daisy

 

[Daisy]

Mit XCode 2.2 und Script Editor 2.1.1 passiert es nicht.

Hmm meine Tests sagen was anderes - ich hab's vorhin ausprobiert (gleicher Rechner, OS 10.4.4): hier die Ergebnisse:

X-Code 2.2:
[Session started at 2006-02-24 14:05:37 +0100.]
2006-02-24 14:05:41.000 weg[597] "PARAMS"
2006-02-24 14:05:41.532 weg[597] {zwei:{bar1:"bar"}, eins:{foo1:"foooo", foo2:"foooo2"}}

Scripteditor:
{eins:{foo1:"foooo", foo2:"foooo2"}, zwei:{bar1:"bar"}}

Grüße,

Daisy

 

[interpreter]

ich bedanke mich für die Antworten, damit ist der Groschen (trotz Fallschirm und Aufwind) gefallen
Trotzdem eine komische Sache mit dem vertauschen, bin gerade am überlegen was ich machen würde, wenn ich in C einen struct in eine Datei schreibe (z.b. den Header einer *.wav Datei) und beim Einlesen kommt nur Datenmüll an, da ich durch die Vertauschung nicht per sizeof() die Bytes in der richtigen der Reihenfolge abklappern kann.

 

[Daisy]

Zumindest innerhalb von AppleScript werden die Werte auch in Xcode anscheinend in der richtigen Anordnung gespeichert und übergeben. Ich habe noch einen kleinen Test gemacht, siehe zweites Bild.

Hmmm - das erhärtet etwas meine Theorie, die mir vorher so durch den Kopf geschossen kam : Es könnte sich hier einfach nur um eine 'Eigenheit' von NSLog handeln, das das Objekt ja in einen String verwandeln muss ???