variablenbezeichnung erst zur laufzeit erzeugen

[Matthi]

ich brauche hilfe bei der programmierung einer formularauswertung:

problem: formular wird durch php script, dazu werden je nach vorhandensein von datensätzen aus datenbank unterschiedlich viele formularfelder erzeugt.

nun soll der user seine daten in das formular eintragen und diese werden dann an server versandt.

doch dazu muss ich erstmal eine möglichkeit finden, auf die inhalte der felder des formulars zugreifen zu können.
mit javascript: inhalt = document.formular.feld1.value
ist klar.
nur ist allerdings der name des feldes nicht feld1, sondern wird dynamisch erzeugt durch php.
also z.B. feld_1 oder feld_5 und so weiter
an die javascriptfkt. kann ich dann die zahlen 1 oder 5 übergeben

funktion(zahl)
{
document.formular.zahl.value
}
das funzt natürlich nicht.
wie kann man es realisieren, dass wenn zahl = 1 übergeben wird
eben

document.formular.feld_1.value

erzeugt wird?

danke für jede antwort.

[Marcus Budde]

Hi,

wie kann man es realisieren, dass wenn zahl = 1 übergeben wird
eben
document.formular.feld_1.value

Hi,
spontan fallen mir zwei Möglickeiten ein

1. die "saubere":
Du benutzt das elements-Array
zb.B.

function beispielfunktion(elementnummer)
{
...
     bla = document.formularname.elements[elementnummer].value;
...
}

siehe auch http://selfhtml.teamone.de/javascript/objekte/elements.htm#allgemeines

2. die "unsaubere"
Du benutzt die eval() Funktion

function beispielfunktion(elementnummer)
{
...
     eval("bla = document.formularname.feld_"+elementnummer+".value");
...
}

siehe auch http://selfhtml.teamone.de/javascript/objekte/unabhaengig.htm#eval

Grüße,
Marcus

[regenfeld]

Grüssi

wie kann man es realisieren, dass wenn zahl = 1 übergeben wird
eben
document.formular.feld_1.value

1. die "saubere":
   Du benutzt das elements-Array
   zb.B.

2. die "unsaubere"
   Du benutzt die eval() Funktion

3. die Pessimistenlösung:
Du legst dir eine Hilfsvariable an:

function beispielfunktion(zahl)
{
     pipapo = "feld_"+zahl
     bla = document.formularname.pipapo.value;
}

lg regenfeld

[Christian Kruse]

Hoi,

2. die "unsaubere"

Die man eigentlich gar nicht unsauber verwenden muss. Jedes Element ist doppelt verzeichnet:
einmal mit Namen, einmal mit Nummer. Ergo....

Du benutzt die eval() Funktion

tust du genau das nicht :-) Sondern du benutzt den Assoziativen Array:

function beispielfunktion(elementnummer)
{
...
     eval("bla = document.formularname.feld_"+elementnummer+".value");
...
}

function beispielfunktion(elementnummer)
 {
  ...
  var bla = document.formularname["feld_"+elementnummer].value;
  ...
 }

Generell laesst sich

window.document.open()

auch als

window['document'].open()

darstellen. Deshalb finde ich die Nutzung von eval() in solchen Faellen auch total hirnrissig.
Jeder Array in JavaScript laesst sich halt auf die zwei Arten darstellen. Statt

document.formularname.feldname.value

waere auch moeglich

document['formularname']['feldname']['value']

oder, um es auf die spitze zu treiben:

window['document']['forms']['formularname']['elements']['feldname']['value']

Gruesse,
 C'eval ist evil!'K

[regenfeld]

Hallo Christian,

Jeder Array in JavaScript laesst sich halt auf die zwei Arten darstellen. Statt

document.formularname.feldname.value

waere auch moeglich

document['formularname']['feldname']['value']

oder, um es auf die spitze zu treiben:

window['document']['forms']['formularname']['elements']['feldname']['value']

Bist du dir da sicher (wenn man zumindest Punkte setzt) ob das richtig ist?

window['document'].forms['formularname'].elements['feldname'].value

Schreibfehler oder Absicht? Hast du nur die Punkte vergessen, oder sind das tatsächlich mehrdimensionale Arrays? Ich hab nämlich noch nirgends gelesen, dass die JS-Objekte mit mehrdimensionalen Arrays angesprochen werden können, ich dachte immer das ginge nur über den Punkt-Operator!

lg regenfeld

[Christian Kruse]

Hoi,

Bist du dir da sicher (wenn man zumindest Punkte setzt) ob das richtig ist?

window['document'].forms['formularname'].elements['feldname'].value

Das ist genau so richtig wie

window['document']['forms']['formularname']['elements']['feldname']['value']

Schreibfehler oder Absicht? Hast du nur die Punkte vergessen, oder sind das tatsächlich
mehrdimensionale Arrays?

Absicht. Es sind schlicht und ergreifend Arrays. Arrays mit Referenzen auf Objekte.

Ich hab nämlich noch nirgends gelesen, dass die JS-Objekte mit mehrdimensionalen Arrays
angesprochen werden können, ich dachte immer das ginge nur über den Punkt-Operator!

Der Punkt-Operator macht nichts anderes, als auf ein benanntes Feld in einem Array
zuzugreifen. Probier mal folgendes:

var blah = new Array();
blah['blub'] = "xyz";
alert(bla.blub);

Gruesse,
 CK

[regenfeld]

Grüssi CK,

Der Punkt-Operator macht nichts anderes, als auf ein benanntes Feld in einem Array zuzugreifen.

Hmm, ich hab zu engstirnig gedacht anscheinend. Der Punktoperator grefit IMHO nicht auf ein Array zu, sondern generell auf Objekte, noch genauer: Man kann mittels Punktoperator auf Methoden, und Attribute von Objekten zugreifen. Da ja window, forms, elements, ... Objekte der JS-Sprache sind, dachte ich anfangs es müsse auch ein Punkt dazwischen sein.

Woran ich aber nicht gedacht hatte, war dass ja Arrays in Javascript auch nix anderes als Objekte sind.

var blah = new Array();
blah['blub'] = "xyz";
alert(bla.blub);

also greift bla.blub eigentlich - grob gesprochen - nicht auf ein Array zu, sondern genauergesagt auf das Attribut (Variable) 'blub' das Array-Objektes 'bla'. Zusätzlich gibt in JS dann eben auch noch den []-Operator, der anscheinend die selbe Funktionalität besitzt wie der Punktoperator:

Beispiel:

var my = new MyClass();
my.name = "regenfeld" // wäre dann gleichwertig zu my['name'] = "regenfeld";
                      // bei Arrays ist es dann halt umgekehrt

Der []-Operator ist quasi nur ein Gimmick, zur instinktiveren Handhabung von (Array-)Objekten in Javascript, so wie man es aus anderen Programmiersprachen gewöhnt ist. Was, wenn das von mir jetzt korrekt geschlussfolgert wurde, ein weiterer Unterschied zu anderen Sprachen wäre, inbesondere zu Java, wo das ja nicht so gehandhabt wird. da kann nur mittels '.' auf Objekte zugegriffen werden (oder etwa doch?)

So, schätzermativ dürfte das jetzt passen, ich hab einfach zuwenig in Klassen/Objekten als vielmehr in Arrays, und simplen Datentypen gedacht, oder hab ich noch irgendwo nen Denkfehler eingebaut?

lg regenfeld

PS: Sieht aus, als wärs wirklich lohnenswert, mich mal näher mit dem Objekt-Schema von JS auseinanderzusetzen ;-)

[Antje Hofmann]

Hallo regenfeld

toller Thread, der gefällt mir

Der Punkt-Operator macht nichts anderes, als auf ein benanntes Feld in einem Array zuzugreifen.

Hmm, ich hab zu engstirnig gedacht anscheinend. Der Punktoperator grefit IMHO nicht auf ein Array zu, sondern generell auf Objekte, noch genauer: Man kann mittels Punktoperator auf Methoden, und Attribute von Objekten zugreifen. Da ja window, forms, elements, ... Objekte der JS-Sprache sind, dachte ich anfangs es müsse auch ein Punkt dazwischen sein.

Das stimmt auch. Um das Verständnis zu vertiefen. Dies gilt ausschließlich für assoziative Arrays.

Woran ich aber nicht gedacht hatte, war dass ja Arrays in Javascript auch nix anderes als Objekte sind.

var blah = new Array();
blah['blub'] = "xyz";
alert(bla.blub);

Aber:  blah[0]="abc";
       alert(blah.0);

geht nicht.

also greift bla.blub eigentlich - grob gesprochen - nicht auf ein Array zu, sondern genauergesagt auf das Attribut (Variable) 'blub' das Array-Objektes 'bla'.

genau, die Zuweisung blah["blub"] erzeugt also keine Eintrag in der Liste der Element des assoziativen Arrays, sondern legt die Eigenschaft 'bla' an.

Zusätzlich gibt in JS dann eben auch noch den []-Operator, der anscheinend die selbe Funktionalität besitzt wie der Punktoperator:

jaein
Möchtest du auf den Index eines Elementes zugreifen, dann sind die Klammern zwingend notwendig.

z.B. bei alert(blah[0]);

Beispiel:

var my = new MyClass();
my.name = "regenfeld" // wäre dann gleichwertig zu my['name'] = "regenfeld";
                      // bei Arrays ist es dann halt umgekehrt

auch wieder ein jain

function MyClass(name)
 { this.name=name }

var my = new MyClass("regenfeld");
 var my2 = new MyClass("regenfeld2");

hier klappt es bequem mit

alert(my.name)
alert (my2.name)

alert(my["name"])
alert (my2["name"])

machst du aber folgendes:

my.vorname="keine Ahnung";
geht alert(my["vorname"]) und alert(my.vorname)

für my2 aber nicht.

Der []-Operator ist quasi nur ein Gimmick, zur instinktiveren Handhabung von (Array-)Objekten in Javascript, so wie man es aus anderen Programmiersprachen gewöhnt ist.

oder anders ausgedrückt mit [] kannst du Objekteigenschaften oder indizie ansprechen.
Er ersetzt quasi den Punktoperator. Ist ein zusätzliches Feateare.

So, schätzermativ dürfte das jetzt passen, ich hab einfach zuwenig in Klassen/Objekten als vielmehr in Arrays, und simplen Datentypen gedacht, oder hab ich noch irgendwo nen Denkfehler eingebaut?

Ein Array ist ein Objekt und kann deshalb eben auch Objekteigenschaften haben. Zusätzlich kann aber auch ein Array eine indizierte Liste von Elementen besitzen.

PS: Sieht aus, als wärs wirklich lohnenswert, mich mal näher mit dem Objekt-Schema von JS auseinanderzusetzen ;-)

Ja ist es, hinter js steht mehr als die meisten erwarten und glauben.

Viele Grüße

Antje

[regenfeld]

Hallo Antje

toller Thread, der gefällt mir

Mir auch :o) Oft entsteht eben durch Zufall, oft aus einem Missverständnis ganz interessante Fragen, hier ist der (so ziemlich einzige?) Platz wo es Leute gibt, die sich dann auch darauf einlassen, wenn der Thread ein wenig abdriftet. Drum fühl ich mich hier auch so pudelwohl *g*

Hmm, ich hab zu engstirnig gedacht anscheinend. Der Punktoperator grefit IMHO nicht auf ein Array zu, sondern generell auf Objekte, noch genauer: Man kann mittels Punktoperator auf Methoden, und Attribute von Objekten zugreifen. Da ja window, forms, elements, ... Objekte der JS-Sprache sind, dachte ich anfangs es müsse auch ein Punkt dazwischen sein.

Das stimmt auch. Um das Verständnis zu vertiefen. Dies gilt ausschließlich für assoziative Arrays.

var blah = new Array();
blah['blub'] = "xyz";
alert(bla.blub);

Aber:  blah[0]="abc";
       alert(blah.0);

geht nicht.

Aber rein theoretisch ist das Konzept hier ein wenig löchrig. Einerseits die strikt durchgezogene Objekt-Orientierung, da geht einer her und macht ein Array einfach zu einem Object, und schafft so die geniale Möglichkeit, objekt-orientiert mit diesen (dann komplexen) Datentypen umzugehen, und dann andererseits, wird eine Ausnahme gemacht, für indizierte Arrays, die werden dann behandelt wie simple Datentypen (strings, integers, ...)

Ich fänds schöner, bzw. das Konzept irgendwie "kompletter" wenn sie die Sache mit dem []-Operator entweder ganz durchziehen würden, oder gar nicht. Methoden lassen sich ja schliesslich auch nicht über [] aufrufen. Ich finde das sehr verwirrend, dass Arrays einerseits wie Objekte behandelt werden, bis auf den (der strengen Definition nach) eigentlichen Sinnes eines (indizierten) Arrays.

Da hinkt bei mir die Sache noch ein wenig, da bick ich nicht so ganz durch, was der Sinn dahinter sein soll.

also greift bla.blub eigentlich - grob gesprochen - nicht auf ein Array zu, sondern genauergesagt auf das Attribut (Variable) 'blub' das Array-Objektes 'bla'.

genau, die Zuweisung blah["blub"] erzeugt also keine Eintrag in der Liste der Element des assoziativen Arrays, sondern legt die Eigenschaft 'bla' an.

'blub' nicht 'bla' - wenn ich mich nicht irre ;-)

Arbeitshypothese:
<script>
var a = new Object();
a['name'] = "regenfeld";
a[0] = "hat die Adresse";
a['email'] = "[e-mail]";

alert (a.name + " " + a[0] + " " + a['email']);
</script>

Also kann das indizierte Array-Element nicht als property abgelegt werden, nona, schliesslich sind ja auch keine Zahlen als Bezeichner erlaubt. Die Frage ist halt, als was werden sie dann abgelegt? Irgendwie müssen sie ja rein ins Objekt!

Anmerkung: Hab gerade in meiner Javascript-Bibel nachgelesen - nachdem ich obiges geschrieben habe! Ich habs aber stehengelassen, um meinen (wies scheint) Denkfehler zu verdeutlichen. Es werden nämlich nicht Arrays als Objekte gehandhabt, sondern Objekte intern als assoziative Arrays!

<zitat quelle="http://www.oreilly.com/catalog/jscript3/">
Javascript Objects are actually implemented internally as associative arrays. The . notation for accessing properties makes them seem like the static objects of C++ and Java, and they work perfectly well in that capacity. But they also have the powerful ability to assotiate values with arbitrary strings.
</zitat>

function MyClass(name)
{ this.name=name }

var my = new MyClass("regenfeld");
var my2 = new MyClass("regenfeld2");

hier klappt es bequem mit

alert(my.name)
alert(my2.name)

alert(my["name"])
alert(my2["name"])

machst du aber folgendes:

my.vorname="keine Ahnung";
geht alert(my["vorname"]) und alert(my.vorname)

für my2 aber nicht.

Obige anmerkung würde auch das erklären. Allerdings nicht dass das:

MyClass.prototype.vorname="keine Ahnung";

alert(my2["vorname"]);
alert(my2.vorname)

funktioniert, oder zumindest irgendwie kompliziert implementiert wurde. Ich hab jetzt voll den Überblick verloren. Daher eine Zusammenfassung meiner Verständnisprobleme:

Varainte 1) Assoziative Arrays sind Objekte. Unklar: Was sind dann "normale" (indizierte) Arrays?

Variante 2) Objekte werden intern als assoziative Arrays behandelt. Unklar: Wie kommen dann die Methoden ins Spiel. Und auch die Unklarheit, wie indizierte arrays dann abgelegt würden bleibt. Alles in allem wär mir obige Variante noch eher verständlich.

PS: Sieht aus, als wärs wirklich lohnenswert, mich mal näher mit dem Objekt-Schema von JS auseinanderzusetzen ;-)

Ja ist es, hinter js steht mehr als die meisten erwarten und glauben.

ja, das hab ich so langsam auch entdeckt, und es gefällt mir sehr gut, das ganze Konzept von JS, ... bis auf diese Sache hier *fg* die ich nicht kapier ;-) Ausserdem hatt ich schon kürzlich einen sehr interessanten Thread zu diesem Thema, find ich höllisch spannend, die OO-Klassen-Thematik in Javascript!

lg regenfeld

PS: Auf das Ausgangsproblem zurückkommen, steht auch was in meiner Bibel:

<zitat quelle="http://www.oreilly.com/catalog/jscript3/">
object.prperty
object["property"]

The important difference to note between these two syntaxes is that in the first, the property name is an identifier, and in the second, the property name is a string.

[...]

When you use the . operator to access a property of an object, however, the name of the property is expressed as an identifier. Identifiers must be typed literally into your Javascript program -- they are not a data type, so they cannot be manipulated by the program.

On the other hand, when you access a propert of an object with the [] array notation, the name of the property is expressed as a string. Strings are Javascript data Types, so they can be manipulated and created while a program is running. So, for example, you could write the following code in Javascript:

var addr = "";
for (i = 0; i<4; i++) {
   addr += customer["address"+i]
  }

This code reads and concatenates the address0, address1, adress2 and address3 properties of the customer object.
</zitat>

... schade dass es in Englisch ist, aber hier sind ohnehin auch auf deutsch so viele Schlagwörter gefallen, dass der suchende diesen Thread schon finden müsste ;-)

[Antje Hofmann]

Hi regenfeld

Mir auch :o) Oft entsteht eben durch Zufall, oft aus einem Missverständnis ganz interessante Fragen, hier ist der (so ziemlich einzige?) Platz wo es Leute gibt, die sich dann auch darauf einlassen, wenn der Thread ein wenig abdriftet. Drum fühl ich mich hier auch so pudelwohl *g*

ja deshalb ändere ich mal den threadtitel, weil das Thema interessant ist

vorweg, ich bin kein Theoretiker, das heißt, ich reime mir zusammen was meiner Ansicht und meiner Praxiserfahrung nach stimmen könnte.

Aber rein theoretisch ist das Konzept hier ein wenig löchrig. Einerseits die strikt durchgezogene Objekt-Orientierung, da geht einer her und macht ein Array einfach zu einem Object, und schafft so die geniale Möglichkeit, objekt-orientiert mit diesen (dann komplexen) Datentypen umzugehen, und dann andererseits, wird eine Ausnahme gemacht, für indizierte Arrays, die werden dann behandelt wie simple Datentypen (strings, integers, ...)

sehe ich eigentlich nicht so. Eher dahingehend, dass die zusätzliche objektorientierte Betrachtung der Arrays ein Bonuns ist

Ich fänds schöner, bzw. das Konzept irgendwie "kompletter" wenn sie die Sache mit dem []-Operator entweder ganz durchziehen würden, oder gar nicht. Methoden lassen sich ja schliesslich auch nicht über [] aufrufen. Ich finde das sehr verwirrend, dass Arrays einerseits wie Objekte behandelt werden, bis auf den (der strengen Definition nach) eigentlichen Sinnes eines (indizierten) Arrays.

Da hinkt bei mir die Sache noch ein wenig, da bick ich nicht so ganz durch, was der Sinn dahinter sein soll.

hier sehe ich es als Pragmatiker.
Ein Array ist eine Liste von Elementen. Diese Elemente haben bestimmte Eigenschaften.
Gleichzeitig ist ein Array auch ein Object und dieses Objekt hat auch wieder bestimmte Eigenschaften oder auch nicht :-)

Theoretisch ist das sehr schwer zu erklären. Praktisch ist das jedoch extrem einfach zu erklären.

<abschweif>
JavaScript ist eben weiblich. Das heißt, es besitzt faßbare und unfaßbare Eigenschaften der Weiblichkeit.
JavaScript in Browsern (IE, NN4, Opera, NN6) ist die Umsetzung von
JavaScript, jedes regiert anders überraschend weiblich.
</abschweif>

übersetzt heißt das, weil JS eben eine Frau ist, muß man manches in Kauf nehmen ;-)

also greift bla.blub eigentlich - grob gesprochen - nicht auf ein Array zu, sondern genauergesagt auf das Attribut (Variable) 'blub' das Array-Objektes 'bla'.

exakt

genau, die Zuweisung blah["blub"] erzeugt also keine Eintrag in der Liste der Element des assoziativen Arrays, sondern legt die Eigenschaft 'bla' an.

wieder richtig

'blub' nicht 'bla' - wenn ich mich nicht irre ;-)

wer will denn da so kleinlich sein

Arbeitshypothese:
<script>
var a = new Object();
a['name'] = "regenfeld";
a[0] = "hat die Adresse";
a['email'] = "[e-mail]";

alert (a.name + " " + a[0] + " " + a['email']);
</script>

Also kann das indizierte Array-Element nicht als property abgelegt werden, nona, schliesslich sind ja auch keine Zahlen als Bezeichner erlaubt. Die Frage ist halt, als was werden sie dann abgelegt? Irgendwie müssen sie ja rein ins Objekt!

ich denke hier wird einfach die Verarbeitung unterschiedlich gehandelt.

Denn das geht auch:

var blah = new Array();
 blah[0]="abc";
 alert(blah["0"]);

ich denke, ganz einfach, dass ein Stingelement immer als Eigenschaft angesehen wird. Wird aber ein Number-Wert übergeben erfolgt keine Umwandlung in ein String (Eigenschaft) umgekehrt aber schon.

Anmerkung: Hab gerade in meiner Javascript-Bibel nachgelesen - nachdem ich obiges geschrieben habe! Ich habs aber stehengelassen, um meinen (wies scheint) Denkfehler zu verdeutlichen. Es werden nämlich nicht Arrays als Objekte gehandhabt, sondern Objekte intern als assoziative Arrays!

<zitat quelle="http://www.oreilly.com/catalog/jscript3/">
Javascript Objects are actually implemented internally as associative arrays. The . notation for accessing properties makes them seem like the static objects of C++ and Java, and they work perfectly well in that capacity. But they also have the powerful ability to assotiate values with arbitrary strings.
</zitat>

hm, hier könnte ich mich tatsächlich streiten. Es ist sehr schwer zusagen was wie gilt. Ich würde eher dazu tendieren, objekte lassen sich auch als assoziative Arrays behandeln.

<g> tatsächlich ist dieses verhalten sogar ein Diplom-, wenn nicht sogar eine Doktorarbeit wert

function MyClass(name)
{ this.name=name }

var my = new MyClass("regenfeld");
var my2 = new MyClass("regenfeld2");

hier klappt es bequem mit

alert(my.name)
alert(my2.name)

alert(my["name"])
alert(my2["name"])

machst du aber folgendes:

my.vorname="keine Ahnung";
geht alert(my["vorname"]) und alert(my.vorname)

für my2 aber nicht.

Obige anmerkung würde auch das erklären. Allerdings nicht dass das:

MyClass.prototype.vorname="keine Ahnung";

prototype erweitert die Eigenschaft des Objektes MyClass
während my.vorname nur die Eigenschaften des Objektes my erweitert

alert(my2["vorname"]);
alert(my2.vorname)

funktioniert, oder zumindest irgendwie kompliziert implementiert wurde.

Dieser Teil erscheint mir sehr einfach. :-)      ich muß aber zugeben ich habe nicht ohne Grund die Änderung der Objekteigenschaften in die Runde geworfen.

Ich hab jetzt voll den Überblick verloren. Daher eine Z»» usammenfassung meiner Verständnisprobleme:

Varainte 1) Assoziative Arrays sind Objekte. Unklar: Was sind dann "normale" (indizierte) Arrays?

auch objekte

assoziative Arrays sind Objekte (normale Arrays) mit Objekteigenschaften

mit

blah[0]="abc";
blah["du"]=regenfeld

blah[0] nutzt du die Eigenschaften  eines normalen Arrays und mit blah["du"] die Objekteigenschaften des Arrays blah

beides kann nebeneinander existieren und ich finde dieses Feature einfach klasse (<g> js ist eben eine Frau)

Variante 2) Objekte werden intern als assoziative Arrays behandelt. Unklar: Wie kommen dann die Methoden ins Spiel. Und auch die Unklarheit, wie indizierte arrays dann abgelegt würden bleibt. Alles in allem wär mir obige Variante noch eher verständlich.

ich werde es mal im Auge behalten und expirimentieren
mal sehen was ich finde (Praktikerin eben)
insgesamt denke ich indizierte Arrays über Number angesprochen spricht auch nur die Number-Eigenschaft an. Während über string angesprochen eben die Stringeigenschaft anspricht und diese gegenenfalls umwandelt.

PS: Sieht aus, als wärs wirklich lohnenswert, mich mal näher mit dem Objekt-Schema von JS auseinanderzusetzen ;-)

Ja ist es, hinter js steht mehr als die meisten erwarten und glauben.

ja, das hab ich so langsam auch entdeckt, und es gefällt mir sehr gut, das ganze Konzept von JS, ... bis auf diese Sache hier *fg* die ich nicht kapier ;-) Ausserdem hatt ich schon kürzlich einen sehr interessanten Thread zu diesem Thema, find ich höllisch spannend, die OO-Klassen-Thematik in Javascript!

ich glaube, dass ist insgesamt  ein wenig erforschtest thema
mal sehen wenn ich luft finde werde ich mal weiter experimentieren und gegebenenfalls posten

Viele Grüße

Antje

[Christian Kruse]

Hoi,

vorweg, ich bin kein Theoretiker, das heißt, ich reime mir zusammen was meiner Ansicht
und meiner Praxiserfahrung nach stimmen könnte.

Ein bisschen theoretisieren macht aber doch Spass ;-)

Aber rein theoretisch ist das Konzept hier ein wenig löchrig. Einerseits die strikt
durchgezogene Objekt-Orientierung, da geht einer her und macht ein Array einfach zu
einem Object, und schafft so die geniale Möglichkeit, objekt-orientiert mit diesen (dann
komplexen) Datentypen umzugehen, und dann andererseits, wird eine Ausnahme
gemacht, für indizierte Arrays, die werden dann behandelt wie simple Datentypen
(strings, integers, ...)

In JS sind auch Integer und Strings Objekte. Oder wie erklaerst du dir sonst folgendes:

var stringob = "ganz langer string";
alert(stringob.length);
alert(stringob.indexOf("g"));

Das finde ich ueberigens sehr konsequent, im Gegensatz zur grossen Schwester Java: dort
*gibt* es noch elementare Datentypen.
Aber mal was anderes: wie kommst du auf die Idee, dass, nur weil man nicht mit dem
.-Operator auf nummerisch indizierte Array-Elemente zugreifen kann, sie keine Objekte mehr
sind? [] ist lediglich ein Operator, in anderen Programmiersprachen kann er sogar ueberladen
werden (Ueberladen in JS, das waer doch mal was :-)
Neee, mich stoert was komplett anderes: wieso zum Teufel sind alle Objekts-Eigenschaften
und -Methoden public? Das widerspricht dem OO-Prinzip doch wohl voellig.

Ich fänds schöner, bzw. das Konzept irgendwie "kompletter" wenn sie die Sache mit
dem []-Operator entweder ganz durchziehen würden, oder gar nicht. Methoden lassen
sich ja schliesslich auch nicht über [] aufrufen. Ich finde das sehr verwirrend, dass Arrays
einerseits wie Objekte behandelt werden, bis auf den (der strengen Definition nach)
eigentlichen Sinnes eines (indizierten) Arrays.

Da hinkt bei mir die Sache noch ein wenig, da bick ich nicht so ganz durch, was der
Sinn dahinter sein soll.

hier sehe ich es als Pragmatiker.
Ein Array ist eine Liste von Elementen. Diese Elemente haben bestimmte Eigenschaften.
Gleichzeitig ist ein Array auch ein Object und dieses Objekt hat auch wieder bestimmte
Eigenschaften oder auch nicht :-)

Ack.

Arbeitshypothese:
<script>
var a = new Object();
a['name'] = "regenfeld";
a[0] = "hat die Adresse";
a['email'] = "[e-mail]";

alert (a.name + " " + a[0] + " " + a['email']);
</script>

Also kann das indizierte Array-Element nicht als property abgelegt werden, nona,
schliesslich sind ja auch keine Zahlen als Bezeichner erlaubt. Die Frage ist halt, als
was werden sie dann abgelegt? Irgendwie müssen sie ja rein ins Objekt!

Intern wird es, denke ich, eine Liste geben. Aber das duerfte Implementierungs-abhaengig sein.

Denn das geht auch:

var blah = new Array();
blah[0]="abc";
alert(blah["0"]);

Natuerlich geht das: es wird beim []-Operator eine INT-Zahl erwartet und dadurch verursachst
du einen impliziten Typecast.

Gruesse,
 CK

[Calocybe]

Huhu!

Ein bisschen theoretisieren macht aber doch Spass ;-)

Und ist beim Loesen praktischer Probleme manchmal aeusserst vorteilhaft.

In JS sind auch Integer und Strings Objekte.

Nicht zwingend. Es gibt einerseits die ordinaeren Typen Number und String, andererseits auch Number-Objekte und String-Objekte.

Oder wie erklaerst du dir sonst folgendes:
var stringob = "ganz langer string";
alert(stringob.length);
alert(stringob.indexOf("g"));

Vielleicht besonders automagische Typkonversion? (Normalerweise wuerde man trotz der automatischen Konversion nicht erwarten, dass JS sich irgendein Objekt raussucht, das zufaellig diese Eigenschaften hat. Daher denke ich, sind die eingebauten Objekte schon etwas bessergestellt als normale.)
Jedenfalls sehe man sich z.B. das an:
  a = "foo"; b = new String("foobar");
  alert(a.length); alert(b.length);
  alert(typeof(a)); alert(typeof(b));
Ergibt: 3/6/string/object

Das finde ich ueberigens sehr konsequent, im Gegensatz zur grossen Schwester Java: dort
*gibt* es noch elementare Datentypen.

Hier eben auch. Und das kann Fallen in sich bergen. Fuer Boolean gilt dasselbe wie Number, es gibt einen Basistyp und einen Objekttyp. Und dann kommt sowas raus:
  a = true; b = new Boolean(true);
  if (a) { /* wird ausgefuehrt */ }
  if (b) { /* wird nicht ausgefuehrt */ }

Ach ja, und es koennte sein, dass es den Basistyp Array gibt und den entsprechenden Objekttyp. Da bin ich mir noch nicht sicher.

Neee, mich stoert was komplett anderes: wieso zum Teufel sind alle Objekts-Eigenschaften
und -Methoden public? Das widerspricht dem OO-Prinzip doch wohl voellig.

JS ist doch keine richtige OO-Sprache. Es ist nicht mehr als ein Spielzeug! Oder glaubst Du vielleicht, MS Access ist eine Datenbank? ;-)

Denn das geht auch:
var blah = new Array();
blah[0]="abc";
alert(blah["0"]);

Natuerlich geht das: es wird beim []-Operator eine INT-Zahl erwartet und dadurch verursachst
du einen impliziten Typecast.

Ich wuerde nicht sagen, dass da ein Int erwartet wird, eben weil Arrays ja normalerweise assoziative sind. Aber folgendes scheint Dir recht zu geben:
  a = ["x", "y", "z"]; a.jkl = "xyz"; a["56"] = "foo";
  for (var i in a) alert(typeof(i));
  alert(a.length)
Ergibt: number/number/number/string/number/57

Man beachte das letzte number! Obwohl das Array spaetestens nach der a.jkl-Zuweisung zweifellos ein assoziatives ist, wird "56" in eine Zahl konvertiert.

So long

[Christian Kruse]

Hoi Calo,

Ein bisschen theoretisieren macht aber doch Spass ;-)

Und ist beim Loesen praktischer Probleme manchmal aeusserst vorteilhaft.

Genau.

In JS sind auch Integer und Strings Objekte.

Nicht zwingend. Es gibt einerseits die ordinaeren Typen Number und String, andererseits
auch Number-Objekte und String-Objekte.

Der Unterschied ist aber durch die automagische Typenkonvertierung fast nicht gegeben,
siehe auch weiter unten.

Oder wie erklaerst du dir sonst folgendes:
var stringob = "ganz langer string";
alert(stringob.length);
alert(stringob.indexOf("g"));

Vielleicht besonders automagische Typkonversion? (Normalerweise wuerde man trotz der
automatischen Konversion nicht erwarten, dass JS sich irgendein Objekt raussucht, das
zufaellig diese Eigenschaften hat. Daher denke ich, sind die eingebauten Objekte schon
etwas bessergestellt als normale.)

Ich glaube nicht, dass JS sich ein benutzer-definiertes Objekt 'raussucht bzw. 'raussuchen
kann.

Das finde ich ueberigens sehr konsequent, im Gegensatz zur grossen Schwester Java: dort
*gibt* es noch elementare Datentypen.

Hier eben auch. Und das kann Fallen in sich bergen. Fuer Boolean gilt dasselbe wie
Number, es gibt einen Basistyp und einen Objekttyp. Und dann kommt sowas raus:
  a = true; b = new Boolean(true);
  if (a) { /* wird ausgefuehrt */ }
  if (b) { /* wird nicht ausgefuehrt */ }

Ja, ok. Du hast wohl recht.

Ach ja, und es koennte sein, dass es den Basistyp Array gibt und den entsprechenden
Objekttyp. Da bin ich mir noch nicht sicher.

Das glaube ich ehrlich gesagt nicht.

Neee, mich stoert was komplett anderes: wieso zum Teufel sind alle Objekts-Eigenschaften
und -Methoden public? Das widerspricht dem OO-Prinzip doch wohl voellig.

JS ist doch keine richtige OO-Sprache. Es ist nicht mehr als ein Spielzeug!

Nun, fuer ein Spielzeug ist sie ganz schoen maechtig. Ich hab sogar schonmal einen
Speicherzugriffsfehler mit JS produziert ,-)

Oder glaubst Du vielleicht, MS Access ist eine Datenbank? ;-)

Der Geist ist willig, aber das Fleisch ist schwach ;-))

Denn das geht auch:
var blah = new Array();
blah[0]="abc";
alert(blah["0"]);

Natuerlich geht das: es wird beim []-Operator eine INT-Zahl erwartet und dadurch verursachst
du einen impliziten Typecast.

Ich wuerde nicht sagen, dass da ein Int erwartet wird, eben weil Arrays ja normalerweise
assoziative sind. Aber folgendes scheint Dir recht zu geben:

Nee, sind sie nicht. Die Normal-Form von Arrays sind nummerische, als Liste oder
als Speicherfeld implementiert.

a = ["x", "y", "z"]; a.jkl = "xyz"; a["56"] = "foo";
  for (var i in a) alert(typeof(i));
  alert(a.length)
Ergibt: number/number/number/string/number/57

Das finde ich weniger verwunderlich.

Man beachte das letzte number! Obwohl das Array spaetestens nach der a.jkl-Zuweisung
zweifellos ein assoziatives ist, wird "56" in eine Zahl konvertiert.

In JS gibt es in der Art keine rein assoziativen Arrays. Das hatten wir ja schon geklaert:
es sind Objekts-Eigenschaften.

Gruesse,
 CK

[Calocybe]

Moin moin!

In JS sind auch Integer und Strings Objekte.
Nicht zwingend. Es gibt einerseits die ordinaeren Typen Number und String, andererseits
auch Number-Objekte und String-Objekte.
Der Unterschied ist aber durch die automagische Typenkonvertierung fast nicht gegeben,
siehe auch weiter unten.

Das stimmt schon, aendert aber nichts an der Tatsache. ;-)

Ich glaube nicht, dass JS sich ein benutzer-definiertes Objekt 'raussucht bzw. 'raussuchen
kann.

So hatte ich's gemeint.

Ach ja, und es koennte sein, dass es den Basistyp Array gibt und den entsprechenden
Objekttyp. Da bin ich mir noch nicht sicher.
Das glaube ich ehrlich gesagt nicht.

Nun, zum Durchtesten fehlt mir ein Grund. Eigentlich interessiert's mich naemlich gar nicht. *g*

Nun, fuer ein Spielzeug ist sie ganz schoen maechtig. Ich hab sogar schonmal einen
Speicherzugriffsfehler mit JS produziert ,-)

Naja, das war dann ein Bug in der Implementation.
Ich sag ja nicht, dass JS so schlecht ist wie Basic. Aber fuer meine Ansprueche sind beides Spielzeuge. :-)

Nee, sind sie nicht. Die Normal-Form von Arrays sind nummerische, als Liste oder
als Speicherfeld implementiert.

In JS auch, findest Du? Wieso solltes das so sein?

a = ["x", "y", "z"]; a.jkl = "xyz"; a["56"] = "foo";
  for (var i in a) alert(typeof(i));
  alert(a.length)
Ergibt: number/number/number/string/number/57

Das finde ich weniger verwunderlich.

Unter der Voraussetzung, dass einfache numerische Arrays die Normalform sind, ist es das auch nicht. Fuer mich aber schon. ;-)

In JS gibt es in der Art keine rein assoziativen Arrays. Das hatten wir ja schon geklaert:
es sind Objekts-Eigenschaften.

Eigentlich hatte wir das umgekehrte geklaert, naemlich das Objekte als assoziative Arrays realisiert werden.

So long

[Christian Kruse]

Hoi,

Das stimmt schon, aendert aber nichts an der Tatsache. ;-)

Hab ich auch nicht behauptet ;-) Es war nur eine Erklaerung, wie ich auf die Annahme gekommen
war.

Ich glaube nicht, dass JS sich ein benutzer-definiertes Objekt 'raussucht bzw. 'raussuchen
kann.

So hatte ich's gemeint.

Dann sind wir uns ja einig ;-)

Nun, fuer ein Spielzeug ist sie ganz schoen maechtig. Ich hab sogar schonmal einen
Speicherzugriffsfehler mit JS produziert ,-)

Naja, das war dann ein Bug in der Implementation.

Nee. War Implementations-Unabhaengig, war ein Bug im Script.

Ich sag ja nicht, dass JS so schlecht ist wie Basic. Aber fuer meine Ansprueche sind beides
Spielzeuge. :-)

Nun, IMHO kann man mit JS einige schoene Dinge machen.

Nee, sind sie nicht. Die Normal-Form von Arrays sind nummerische, als Liste oder
als Speicherfeld implementiert.

In JS auch, findest Du? Wieso solltes das so sein?

Weil das eigentlich die allgemeine Form von 'Array' ist. Und meinen Erfahrungen nach wird das
bestaetigt.

a = ["x", "y", "z"]; a.jkl = "xyz"; a["56"] = "foo";
  for (var i in a) alert(typeof(i));
  alert(a.length)
Ergibt: number/number/number/string/number/57

Das finde ich weniger verwunderlich.

Unter der Voraussetzung, dass einfache numerische Arrays die Normalform sind, ist es das
auch nicht. Fuer mich aber schon. ;-)

;-)

Gruesse,
 CK

[Calocybe]

Hi Bernhard!

Aber:  blah[0]="abc";
       alert(blah.0);
geht nicht.

Natuerlich nicht, denn 0 und ueberhaupt einfach Zahlen sind keine gueltigen Bezeichner in JS. Man kann sie also nicht als Property hinschreiben. Das hat aber mit Objekten oder Arrays zu tun.

Aber rein theoretisch ist das Konzept hier ein wenig löchrig.

Nicht nur hier. Ueberhaupt passieren in JS immer mal Dinge, die voellig unlogisch sind. "Automagics" nennt man sowas. Ich hasse das.

Anmerkung: Hab gerade in meiner Javascript-Bibel nachgelesen - nachdem ich obiges geschrieben habe! Ich habs aber stehengelassen, um meinen (wies scheint) Denkfehler zu verdeutlichen. Es werden nämlich nicht Arrays als Objekte gehandhabt, sondern Objekte intern als assoziative Arrays!

Genau so isses!

machst du aber folgendes:
my.vorname="keine Ahnung";
geht alert(my["vorname"]) und alert(my.vorname)
für my2 aber nicht.

Wieso soll das fuer my2 nicht gehen?

Obige anmerkung würde auch das erklären. Allerdings nicht dass das:
MyClass.prototype.vorname="keine Ahnung";
alert(my2["vorname"]);
alert(my2.vorname)
funktioniert, oder zumindest irgendwie kompliziert implementiert wurde.

Ja, JS' Auffassung von Vererbung. Wird eine Property nicht direkt im Objekt gefunden, wird im Prototyp danach gesucht. Ist mir jetzt zu aufwendig zu erklaeren. In der Netscape-Doku ist es aber ausfuehrlich beschrieben.

Varainte 1) Assoziative Arrays sind Objekte. Unklar: Was sind dann "normale" (indizierte) Arrays?

Da es nicht so ist, stellt sich die Frage ja nicht. ;-) Na zumindest nicht so.

Variante 2) Objekte werden intern als assoziative Arrays behandelt. Unklar: Wie kommen dann die Methoden ins Spiel.

Ganz einfach. Methoden sind auch nur ganz normale Properties. Sie haben nicht den Typ number, string oder sowas, sondern eben den Typ function. Hat man eine Variable X dieses Typs, kann man mit X() die Funktion/Methode aufrufen.

Und auch die Unklarheit, wie indizierte arrays dann abgelegt würden bleibt.

Assoziative Arrays bedeutet ja eine Key->Value Zuordnung. Aber wer sagt, dass man als Key nur einen String nehmen kann? Eine Zahl tut's doch genauso.

Alles in allem wär mir obige Variante noch eher verständlich.

Mir nicht. ;-)

Ja ist es, hinter js steht mehr als die meisten erwarten und glauben.

Ich finde, es ist mit seinen Automagics unnoetig kompliziert. Letztlich kann man sowieso nicht sauber damit programmieren.

ja, das hab ich so langsam auch entdeckt, und es gefällt mir sehr gut, das ganze Konzept von JS, ... bis auf diese Sache hier *fg* die ich nicht kapier ;-) Ausserdem hatt ich schon kürzlich einen sehr interessanten Thread zu diesem Thema, find ich höllisch spannend, die OO-Klassen-Thematik in Javascript!

Kannst ja mal im Archiv nach "Kontinuum" suchen, da sollte sich noch mehr darueber finden. Dort muessten auch entsprechende Links in die Netscape-Doku stehen, wo noch so einiges mehr erklaert ist.

So long

[Joachim]

hi,

Punkte sind falsch, den es _sind_ arrays. Teste:

<html>
<head>
</head>
<body>
<table cellspacing="0" cellpadding="10" border="0">
<tr>
 <td><h3>window</h3></td>
 <td><h3>document</h3></td>
</tr>
<tr>
 <td valign="top">
  <script language="javascript1.2">
  for(var i in window) document.write(i + " : " + self[i] + "<br>");
  </script>
 </td>
 <td valign="top">
  <script language="javascript1.2">
  for(var j in document) document.write(j + " : " + document[j] + "<br>");
  </script>
 </td>
</tr>
</table>
</body>
</html>

hth + Gruss  Joachim