nicht angemeldet
Der Martin
Struppi
Struppi
Struppi
Struppi
Struppi
Der Martin
Struppi
Grüße,
die frage habe ich schon mal letztes jahr gestellt, damals kam es aber zu keinem ergebniss. deswegen formuliere ich die um - vltl kennt jemand die antwort :)
gegeben ist ein gitter von AxB feldern. in diesem gitter können objekte platziert werden die mehr als ein feld belegen können.
über ansprache der felder will ich nun auf das object kommen können.
wenn ich nun ein object mehreren feldern als kind zuweise - habe ich in JS dann n kopien oder zeiger auf das gleiche object?
MFG
bleicher
Hallo,
gegeben ist ein gitter von AxB feldern. in diesem gitter können objekte platziert werden die mehr als ein feld belegen können.
so 'ne Art Spielfeld für "Schiffe versenken"?
wenn ich nun ein object mehreren feldern als kind zuweise - habe ich in JS dann n kopien oder zeiger auf das gleiche object?
Javascript kennt zwar Referenzen - bei der Zuweisung wird aber AFAIK eine Kopie daraus.
Ich würde daher die Objekte getrennt vom Spielfeld als numerisch indiziertes Array vorhalten, und in den Gitterfeldern jeweils den Index des zugewiesenen Objekts. Dann können mehrere Felder denselben Index enthalten und somit auf dasselbe Objekt verweisen.
Ciao,
Martin
wenn ich nun ein object mehreren feldern als kind zuweise - habe ich in JS dann n kopien oder zeiger auf das gleiche object?
Javascript kennt zwar Referenzen - bei der Zuweisung wird aber AFAIK eine Kopie daraus.
Nein, nur bei sogenannten primitives.
number, string und bool Werte werden kopiert, alles andere wird referenziert.
Struppi.
Grüße,|
Javascript kennt zwar Referenzen - bei der Zuweisung wird aber AFAIK eine Kopie daraus.
Nein, nur bei sogenannten primitives.
number, string und bool Werte werden kopiert, alles andere wird referenziert.
ich mache heute den einfachen test - aber interessant sit die theorie dahinter zu kennen^^
MFG
bleicher
Grüße,
habe ich alles bedacht?
var felder=new Array();
var testobject={eigenschaft:"erster"}
alert(testobject.eigenschaft);//erster
felder[2]=testobject;
felder[54]=testobject;
alert(felder[2].eigenschaft);//erster
alert(felder[54].eigenschaft);//erster
testobject.eigenschaft="zweiter";
alert(felder[2].eigenschaft);//zweiter
alert(felder[54].eigenschaft);//zweiter
MFG
bleicher
habe ich alles bedacht?
Das Beispiel zeigt die Wirkung der Referenzen, wenn du das meinstest.
Struppi.
Grüße,
Das Beispiel zeigt die Wirkung der Referenzen, wenn du das meinstest.
gut soweit simma - und wie erzingt man kopieren? die frage war nach dem steuern des verhaltens - defautl sidn referenzen. und wenn man kopien will?
MFG
bleicher
Das Beispiel zeigt die Wirkung der Referenzen, wenn du das meinstest.
gut soweit simma - und wie erzingt man kopieren? die frage war nach dem steuern des verhaltens - defautl sidn referenzen. und wenn man kopien will?
Dann muss man kopieren. Bei einem Objekt ein deepcopy, also eine Kopie von jedem Attribut erzeugen. Wenn dieses ein Objekt ist, genau das gleiche nochmal usw. bis du einen primitives Wert erreicht hast.
Struppi.
Grüße,
Dann muss man kopieren. Bei einem Objekt ein deepcopy, also eine Kopie von jedem Attribut erzeugen. Wenn dieses ein Objekt ist, genau das gleiche nochmal usw. bis du einen primitives Wert erreicht hast.
es gibt programmiersprachen die objectorientiert sind und keine banale funktion zum kopieren der objecte anbieten? und JS gehört dazu? ehrlich?
anscheinend ja aber meine güte - die haben schon version 1.8 und diese scheiße wurde nicht hinzugefügt? mamma mia....
MFG
bleicher
Dann muss man kopieren. Bei einem Objekt ein deepcopy, also eine Kopie von jedem Attribut erzeugen. Wenn dieses ein Objekt ist, genau das gleiche nochmal usw. bis du einen primitives Wert erreicht hast.
es gibt programmiersprachen die objectorientiert sind und keine banale funktion zum kopieren der objecte anbieten? und JS gehört dazu?
Das ist völlig normal. Welche Sprache kennst du, die so eine Funktion im Kern anbietet?
Struppi.
Grüße,
Das ist völlig normal. Welche Sprache kennst du, die so eine Funktion im Kern anbietet?
C++, PHP? oder red ich grade scheiße?
MFG
bleicher
Das ist völlig normal. Welche Sprache kennst du, die so eine Funktion im Kern anbietet?
C++, PHP? oder red ich grade scheiße?
Wäre mir nicht bekannt. Java kennt clone was aber, soweit ich das überblicke, auch kein deepcopy erstellt.
Ich könnte mir vorstellen, dass smalltalk sowas anbietet. Aber wie gesagt, es ist nicht unbedingt normal, dass eine solche Funktionalität vorhanden ist. Denn eine Implementierung ist alles andere als trivial, wenn die Funktion für alle Objekte funktionieren soll.
Struppi.
Hallo,
Das ist völlig normal. Welche Sprache kennst du, die so eine Funktion im Kern anbietet?
C++, PHP? oder red ich grade scheiße?
C++ legt AFAIK automatisch eine Kopie an, wenn ich ein Objekt zuweise, so wie es C schon bei structs macht. Es sei denn, ich weise es an eine Variable zu, die ausdrücklich als Referenz-Typ deklariert ist.
Ciao,
Martin
Grüße,
C++ legt AFAIK automatisch eine Kopie an, wenn ich ein Objekt zuweise, so wie es C schon bei structs macht. by value,zeiger und reference sind schon eines sehr präzise steurungsmöglichkeit.
jo - und PHP kennt den & operator AFAIK auch. JS steht da etwas blöd da :/
MFG
bleicher
C++ legt AFAIK automatisch eine Kopie an, wenn ich ein Objekt zuweise, so wie es C schon bei structs macht. by value,zeiger und reference sind schon eines sehr präzise steurungsmöglichkeit.
Referenzen sind genau das was JS auch nutzt. Zeiger nicht, bringen in dem Fall aber auch keinen Vorteil, nur einen etwas erhöhten Schreibaufwand um das gleiche zu erreichen.
jo - und PHP kennt den & operator AFAIK auch. JS steht da etwas blöd da :/
Inwiefern? JS braucht keinen Operator.
Struppi.
Grüße,
Referenzen sind genau das was JS auch nutzt.
Inwiefern? JS braucht keinen Operator.
doch - wenn ich mal doch keine referenz sondern stinknormalen call-by-value brauche ? manchmal will man ja doch nur eine kopie nutzen.
MFG
bleicher
Referenzen sind genau das was JS auch nutzt.
Inwiefern? JS braucht keinen Operator.
doch - wenn ich mal doch keine referenz sondern stinknormalen call-by-value brauche ? manchmal will man ja doch nur eine kopie nutzen.
Irgendwie wirfst du jetzt eine ganze Menge in einen Topf. Die call-by-value Problematik hatte letztens erst Mathias erklärt. (Mittlerweile hat er den Thread auch hier verlinkt).
Die Frage ist was erwartest du?
Da hier von Pointern die Rede war, diese machen ja im Prinzip auch nichts anderes als Referenzen, nur eben Zeiger auf die Speicherstellen der Referenz. Zeiger gibt aber in JS nicht (wie in Java oder PHP).
Dein Problem ist eher der Unterschied zwischen einer deep copy und einer shallow copy. Eine deep copy erzeugt ein neues Objekt mit allen Eigenschaften des Orginals, was aufwendig ist, deshalb wird es selten gemacht.
Die Dikussion gab es auch schon öfters, Peter hat es mal erklärt.
Struppi.
Hallo,
Da hier von Pointern die Rede war, diese machen ja im Prinzip auch nichts anderes als Referenzen, nur eben Zeiger auf die Speicherstellen der Referenz.
eben, Referenzen sind eigentlich nichts anderes als Zeiger.
Zeiger gibt aber in JS nicht (wie in Java oder PHP).
Doch, nur merkt man das nicht, weil man in den Mechanismus nicht eingreifen kann.
Dein Problem ist eher der Unterschied zwischen einer deep copy und einer shallow copy. Eine deep copy erzeugt ein neues Objekt mit allen Eigenschaften des Orginals, was aufwendig ist, deshalb wird es selten gemacht.
Nun, wie gesagt: In C werden structs grundsätzlich kopiert, nicht referenziert.
typedef struct
{ int index;
long value;
} foo;
foo s1 = { 42, 52705621 };
foo s2; // für s2 wird Speicherplatz reserviert, aber nicht initialisiert
s2 = s1; // s1 wird komplett in den für s2 reservierten Speicher kopiert
s1.index = 10; // jetzt verändern wir s1
printf("%i\n", s2.index); // immer noch 42
Die Dikussion gab es auch schon öfters, Peter hat es mal erklärt.
Ich würde es nicht "erklärt" nennen; vielleicht "geschwafelt".
Ciao,
Martin
Grüße,
diese posts werden bei mir mit zunehmender tiefe echt schmal - ist das ein problem mit meinem broswer in neuer version oder eine veränderung im design -denn früher hatte ich noch horizontaless scrollbar bei sowas?
MFG
bleicher
Hallo,
diese posts werden bei mir mit zunehmender tiefe echt schmal
wieso das? Die Threadstruktur hat bei mir keine Auswirkungen auf die Anzeige des Posting-Texts.
ist das ein problem mit meinem broswer in neuer version oder eine veränderung im design -denn früher hatte ich noch horizontaless scrollbar bei sowas?
Keine Ahnung - in meinem Opera (8.54 ebenso wie 11.0) erscheint ein horizontaler Scrollbalken, wenn der Threadbaum ausufert. Der eigentliche Posting-Text bleibt aber ordentlich bei 100% Breite.
Ciao,
Martin
Grüße,
wieso das? Die Threadstruktur hat bei mir keine Auswirkungen auf die Anzeige des Posting-Texts.
Keine Ahnung - in meinem Opera (8.54 ebenso wie 11.0) erscheint ein horizontaler Scrollbalken, wenn der Threadbaum ausufert. Der eigentliche Posting-Text bleibt aber ordentlich bei 100% Breite.
bei mir seit Opera 10.6 werden die postings bis zu 5 zeichen schmal :( die werden einfach in fensterbreite reingequetscht.
vermutungen zur ursache O_o?
MFG
bleicher
[latex]Mae govannen![/latex]
diese posts werden bei mir mit zunehmender tiefe echt schmal
wieso das? Die Threadstruktur hat bei mir keine Auswirkungen auf die Anzeige des Posting-Texts.
Schalt' mal auf "nested". Ggf. ohne /my/
Aber <abfällig zeigeauf="Nested-Ansicht">sowas</abfällig> benutzt man natürlich ohnehin nicht ;)
ist das ein problem mit meinem broswer in neuer version oder eine veränderung im design -denn früher hatte ich noch horizontaless scrollbar bei sowas?
Keine Ahnung - in meinem Opera (8.54 ebenso wie 11.0) erscheint ein horizontaler Scrollbalken, wenn der Threadbaum ausufert. Der eigentliche Posting-Text bleibt aber ordentlich bei 100% Breite.
Mit meinem eigenen Stylesheet bleibts auch bei nested so.
Cü,
Kai
Grüße,
Mit meinem eigenen Stylesheet bleibts auch bei nested so.
bevorzuge nested - wärest so nett die relevanten teile der CSS zu sharen? spart mir anstarren des quelltextes^^
MFG
bleicher
[latex]Mae govannen![/latex]
Mit meinem eigenen Stylesheet bleibts auch bei nested so.
bevorzuge nested - wärest so nett die relevanten teile der CSS zu sharen? spart mir anstarren des quelltextes^^
Nun, ich benutze »nested« nie, daher habe ich nur rudimentäre Regeln dafür eingebaut und wenige Verschönerungen.
Der wichtigste Teil ist, eine Mindestbreite zu verwenden:
#selfforum-nachricht #nested-root ul ul li {
min-width: 600px;
}
Die Einrückung mache ich so:
#selfforum-nachricht #nested-root ul ul {
margin-left: 2em;
}
Dann wird noch die Einrückung ab einer bestimmten Tiefe begrenzt, indem der Wert von margin-left verringert wird:
#selfforum-nachricht #nested-root ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul ul {
margin-left: 3px;
padding-left: 3px;
border-left: 2px solid #BABABA;
}
Hier werden dann die weiteren Einrückungen durch die Linien, die mit border erzeugt werden, deutlich gemnacht.
Oben sind es 20 ul, das passt für _mein_ Stylesheet, mit dem Standard-Forenstylesheet werden wohl einige weniger
sein müssen. oder aber man scrollt entsprechend nach rechts.
Cü,
Kai
Grüße,
Der wichtigste Teil ist, eine Mindestbreite zu verwenden:
#selfforum-nachricht #nested-root ul ul li {
min-width: 600px;
}
danke - den selctor zusammenzufieln wäre ja das schlimmste^^
MFG
bleicher
--
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_-
[FirefoxMyth](http://www.firefoxmyths.com)
Zeiger gibt aber in JS nicht (wie in Java oder PHP).
Doch, nur merkt man das nicht, weil man in den Mechanismus nicht eingreifen kann.
Nein, du kannst in keiner der beiden Programmiersprachen Speicherstellen manipulieren. Ob diese intern irgendwie genutzt werden, ist für die Problematik unerheblich.
Dein Problem ist eher der Unterschied zwischen einer deep copy und einer shallow copy. Eine deep copy erzeugt ein neues Objekt mit allen Eigenschaften des Orginals, was aufwendig ist, deshalb wird es selten gemacht.
Nun, wie gesagt: In C werden structs grundsätzlich kopiert, nicht referenziert.
In C gibt es auch keine Objekte, nur einfache Datentypen, structs sind lediglich eine Sammlung davon. Einfache Datentypen werden auch in JS kopiert.
Die Dikussion gab es auch schon öfters, Peter hat es mal erklärt.
Ich würde es nicht "erklärt" nennen; vielleicht "geschwafelt".
Es entspricht aber exakt dem was in JS passiert, was paßt dir an der Erklärung nicht?
Struppi.
Die Dikussion gab es auch schon öfters, Peter hat es mal erklärt.
Oh mein Gott. FÜNF JAHRE später ist dieses Forum noch kein Stück weiter. ;)
Grüße,
Oh mein Gott. FÜNF JAHRE später ist dieses Forum noch kein Stück weiter. ;)
sieh es positiv - wir haben nur 5 Jahre gebraucht um am selben Ort zu bleiben, viele andere haben die zeit genutzt um dem Ende näher zu kommen!
Red-Queen-Hypothese in Aktion, nicht war?
MFG
bleicher
Dein Problem ist eher der Unterschied zwischen einer deep copy und einer shallow copy. Eine deep copy erzeugt ein neues Objekt mit allen Eigenschaften des Orginals, was aufwendig ist, deshalb wird es selten gemacht.
Eine dritte Möglichkeit ist, ein Objekt zu erzeugen, das an das zu »kopierende« per Prototyp delegiert. Dafür bietet ECMAScript 5 Object.create(), welches man für Browser, die die Methode noch nicht kennen, nachbauen kann.
Ein Kopieren des gesamten Objekts ist in dem Fall nicht nötig, man hat vielmehr einer Art Copy-on-Write:
var obj = { foo : 1 };
var copy = Object.create(obj);
alert(copy.foo); // Holt »foo« vom Prototyp
alert(copy.hasOwnProperty('foo')); // false
copy.foo++; // Holt »foo« vom Prototyp, aber erzeugt dann eine neue Eigenschaft »foo« bei »copy«
alert(copy.hasOwnProperty('foo')); // true
alert(obj.foo); // 1
alert(copy.foo); // 2
Prototypen verstehen: Die Glasplatten-Metapher
Object.create() ist ziemlich genial. Mit dieser einfachen Möglichkeit, prototypische Delegation umzusetzen, kommt JavaScript endlich zu sich selbst. Mit ES5 kommen zudem noch Property Descriptors hinzu, d.h. wir haben gewisse Zugriffsrechte, Konstanten, Getter/Setter usw.
http://dmitrysoshnikov.com/ecmascript/es5-chapter-1-properties-and-property-descriptors/
http://www.slideshare.net/douglascrockford/newandimproved
http://www.slideshare.net/kangax/say-hello-to-ecmascript-5
http://davidflanagan.com/Talks/es5/slides.html
Mathias
Ein Kopieren des gesamten Objekts ist in dem Fall nicht nötig, man hat vielmehr einer Art Copy-on-Write:
Das funktioniert sogar z.T. mit einem Array:
if (typeof Object.create !== 'function') {
Object.create = function (o) {
function F() {}
F.prototype = o;
return new F();
};
}
var obj = [1,2,3];
var copy = Object.create(obj);
alert(copy[0]); // 1
alert(copy.length); // 3
copy.push(5);
alert(copy.length); // 4
Allerdings funktionieren nicht alle Methoden. toString(), z.b. für ein alert(copy), versagt hier.
Kannte ich schon und hat mir auch geholfen. Ein sehr anschaulicher Artikel über dieses beileibe nicht einfache Thema, vor allem die prototypen sind in ihrem ganzen Verhalten nicht einfach zu verstehen.
Object.create() ist ziemlich genial. Mit dieser einfachen Möglichkeit, prototypische Delegation umzusetzen, kommt JavaScript endlich zu sich selbst.
Leider gibt es viel gemurkse, um OOP Paradigmen in JS umzusetzen, ob die damit wirklich ein Ende haben werden ist eine andere Sache.
Der ganze Kerl - dank Java - erwartet die totale Kapselung. Mir hat der Blog von Andrea Giammarchi in der Hinsicht ein wenig die Augen geöffnet, vor allem der _super bullshit Artikel und better javascript classes.
Wobei ich aber immer noch lieber eine echte Konstruktorfunktion verwende, um eben auch Intialisierungen zu kapseln. Aber das wie in mit Perl, es gibt viele Möglichkeiten etwas zu tun, deshalb ist Javascript toll ;-)
Struppi.
hallo in die runde,
@Struppi, @molily - schoen, Euch mal wieder zu lesen.
Dein Problem ist eher der Unterschied zwischen einer deep copy
und einer shallow copy. Eine deep copy erzeugt ein neues Objekt
mit allen Eigenschaften des Orginals, was aufwendig ist, deshalb
wird es selten gemacht.Die Dikussion gab es auch schon öfters, ...
... Peter hat es mal erklärt.
... und hier auch (am leider nur hingerotzten beispiel):
[Object].equals, [Object].dump, [Object].clone - (Nov. 2006)
... und endlich auch mal ausfuehrlicher, als dann schon klar war,
dass die existenzberechtigung fuer [equals], [dump] und [clone]
in JavaScript fast ausschliesslich in deren verwendung als
lehr- bzw. lernbeispiel begruendet liegt (Maerz. 2008).
objekte werden seit/nach Douglas Crockford und Richard Conford
kopiert, indem sie als prototyp eines anonymen und *leeren*
konstruktors referenziert werden - z.b. so:
var object = (function (blueprint) {
var GreenBody = (function () {});
GreenBody.prototype = blueprint;
return (new GreenBody);
});
auf genau dieser basis steht das von Mathias erwaehnte [Object.create].
so long - peterS. - pseliger@gmx.net
manchmal will man ja doch nur eine kopie nutzen.
Das ist in JavaScript ein mehr hypothetischer Fall - in der Praxis findet man meist einfachere und performantere Lösungen. Die Natur von JavaScript hilft einem dabei weiter.
Klar liegen manche Daten z.B. als Baum von Objects vor. Wenn man hierauf schreibend operieren und das Original erhalten will, dann muss man auf einer Deep Copy arbeiten. Allerdings wäre es dann sinnvoller, diese Operation mit dem Kopieren zu verquicken, sodass letztlich Copy-on-write herauskommt und der Rest durch Referenzen oder Delegation gelöst werden kann. Wie Struppi sagt, vermeidet man Deep Copy wenn es nur geht. Und es geht m.E.n. fast immer. Viel häufiger ist Shallow Copy, das ist in der Regel trivial. Bibliotheken wie PrototypeJS, Mootools oder Yahoo UI bieten einem dazu eine Menge an Helferfunktionen. Die von Yahoo UI habe ich mal in einem Artikel beschrieben.
Mathias
Das ist völlig normal. Welche Sprache kennst du, die so eine Funktion im Kern anbietet?
C++, PHP? oder red ich grade scheiße?C++ legt AFAIK automatisch eine Kopie an, wenn ich ein Objekt zuweise, so wie es C schon bei structs macht.
Das wäre mir neu, dazu musst du für jedes Objekt einen Copy constructor schreiben. Ähnlich dürfte es bei Java mit der clone Methode laufen, das ist ungefähr der Weg, den du auch mit JS beschreiten kannst.
Struppi.
es gibt programmiersprachen die objectorientiert sind und keine banale funktion zum kopieren der objecte anbieten? und JS gehört dazu? ehrlich?
anscheinend ja
Vergiss am besten alles, was dort steht. Man sollte keine LÖSUNGEN diskutieren, ohne eine konkrete AUFGABE formuliert zu haben.
aber meine güte - die haben schon version 1.8 und diese scheiße wurde nicht hinzugefügt? mamma mia....
»Diese Scheiße« wurde absichtlich nicht hinzugefügt, weil sie im Kontext von JavaScript »scheiße« wäre, um es mit deinen Worten zu sagen. Im Übrigen haben »die« schon ECMAScript Edition 5 und dort gibt es - absichtlich - immer noch keine Klon- bzw. Kopierfunktion. So etwas ist auch nicht geplant. Es passt nicht ins Sprachkonzept einer solchen funktionalen und prototypischen Sprache.
Wie gesagt, es gibt sehr viele Fälle von »Kopiere mir ein Object«. Die kann man aber fast immer SPEZIFISCH besser lösen, anstatt in jedem Fall ein Deep Copy draufzuwerfen. Clientseitiges JavaScript operiert ja hauptsächlich auf dem DOM. Das heißt, es gibt einen riesigen Haufen von sogenannten Hosts Objects. Die kann man ohnehin nicht über eine generische Kopiermethode klonen, sondern z.B. über spezifische eingebaute wie etwa bei DOM-Knoten. In den meisten Fällen reicht es, mit Referenzen auf sie zu arbeiten.
Es ist durchaus sinnvoll, die Native und Hosts Objects zu erweitern und an sie zu delegieren. Dazu bietet einem ECMAScript 5 wie gesagt schon viel. In ECMAScript Harmony, dem Nachfolger, sind zudem native Proxies möglich. Damit kann man sich die Arbeit mit Hosts Objects vereinfachen. Genau das machen Bibliotheken wie jQuery oder Prototype bereits, wenn auch auf verschiedene Weisen und noch ohne die Helfer, die die JavaScript-Engines bald bieten werden.
Mathias
wenn ich nun ein object mehreren feldern als kind zuweise - habe ich in JS dann n kopien oder zeiger auf das gleiche object?
Javascript kennt zwar Referenzen - bei der Zuweisung wird aber AFAIK eine Kopie daraus.
Das stimmt so nicht. Dazu hatten wir erst kürzlich eine sehr ausführliche Diskussion:
https://forum.selfhtml.org/?t=202555&m=1368247 ff.
Ich würde daher die Objekte getrennt vom Spielfeld als numerisch indiziertes Array vorhalten, und in den Gitterfeldern jeweils den Index des zugewiesenen Objekts. Dann können mehrere Felder denselben Index enthalten und somit auf dasselbe Objekt verweisen.
Das ist unnötig. Die Felder können direkt Referenzen enthalten. JavaScript legt nie von selbst Kopien von Objects an. Wenn Objects Variablen oder Objekteneigenschaften zugewiesen werden, werden immer Referenzen erzeugt. Das habe ich mit dieser Metapher zu erklären versucht.
Mathias
wenn ich nun ein object mehreren feldern als kind zuweise - habe ich in JS dann n kopien oder zeiger auf das gleiche object?
Wieso probierst du es nicht aus?
var felder = [];
var objekt1 = { i : '1' };
var objekt2 = { i : '2' };
felder[0] = objekt1;
felder[1] = objekt1;
felder[2] = objekt2;
felder[3] = objekt2;
alert(
'0: ' + felder[0].i + '\n' +
'1: ' + felder[1].i + '\n' +
'2: ' + felder[2].i + '\n' +
'3: ' + felder[3].i
);
objekt1.i = '1 neu';
objekt2.i = '2 neu';
alert(
'0: ' + felder[0].i + '\n' +
'1: ' + felder[1].i + '\n' +
'2: ' + felder[2].i + '\n' +
'3: ' + felder[3].i
);
... dürfte deine Frage schon beantworten.
Mathias