nicht angemeldet
Hi,
So ganz kann ich Dir nicht folgen. Wenn Du serverseitig beliebige Daten hinzufügen willst, wie soll dann der "beliebige" Zugriff innerhalb des JS erfolgen? Entweder du reichst die Daten z.B. als dekodiertes JSON-Objekt "einfach durch", dann interessiert es den Compiler nicht. Oder aber du willst auf Details des Objekts zugreifen, dann kann es sich doch aber nur um einen festen Teil der Daten handeln, die das JS auch wirklich "kennt". Genau für den Fall bietet sich ja dann die von Dir schon genannte Schreibweise objekt['key'] an, davon lässt der Compiler per Definition die Finger.
öhm, gute Frage, welche ich mir bislang nicht gestellt habe.
Hat wohl etwas mit Gewohnheit zu tun, dass ich erwarte, dass ich rein client-seitig (also in einer x-beliebigen Funktion, welche erstmal nichts mit dem Server-Interface zu tun hat, aber mit deren Daten hantiert) ein "normales" Objekt erwarte, bei dem ich "wie üblich" mit der Punkt-Notation auf Eigenschaften zugreifen kann.
Was ich persönlich nicht tun würde, wäre, für Datenstrukturen, welche vom Server kommen (könnten) mit der []- und für reine Client-Datenstrukturen die Punkt-Notation nehmen.
Dann müsste ich jedesmal, wenn ich irgendwo drauf zugreife, überlegen, wo die Daten herkommen, was auch potentiell fehlerträchtig ist.
Bliebe also nur, den von dir genannten Weg zu Ende zu gehen und generell mit der Klammer-Notation zugreifen mit dem Nachteil, dass der Compiler dann wiederum die Namen nicht verkürzen kann und ich weniger Code-Einsparung habe. Ansonsten sehe ich da erstmal keine Nachteile dabei, als Vorteil hätte man, dass man den Kopierkonstruktor nicht mehr braucht.
Was ich mir erhoffte, war, dass ich dem Compiler sagen kann: aber hier, bei diesem Typedef, da benennst du das Zeugs aber nicht um (also genau das, was die Klammer-Notation erreicht, aber so daß ich bei der Punkt-Notation bleiben kann). Da habe ich bisher keinen Weg dazu gefunden, und in Anbetracht meiner weitergehenden Überlegungen bzgl Dokumentation habe ich von der einfachen Lösung sowieso Abstand genommen.
Wenn ich die Datenstrukturen erzeugen lasse, kann ich gleichzeitig einen Erzeuger für die Schnittstellen-Dokumentation schreiben und spare mir eben dort Arbeit.
Serverseitig muss ich diese Datenstrukturen (derzeit) nicht erzeugen, weil diese meistens gar nicht explizit beschrieben sind*.
*: Häufig mache ich sowas wie (in PHP, nur verkürzter Pseudocode):
$dbh = mysqli_connect(/* */);
$q = $dbh->query("SELECT bla, blub, ttt FROM mytable");
$ret = array();
while ($item = $r->fetch_object()) {
$ret[] = $item;
}
echo json_encode($ret);
In anderen Programmiersprachen, bei denen man stdclass (oder Object, oder wie die Basisklasse eben heißt) nicht einfach bevölkern darf, müsste ich diese Datenklassen ja auch erzeugen und tlw. mit einem JSON-Serialisierer ausstatten, dies ist also kein wesentlich neues Konstrukt.
Bis die Tage,
Matti