Werte in Dictionary setzen

  • Werte in Dictionary setzen

    Hi Mädels,


    Quellcode

    1. NSMutableDictionary*myDic=[[NSMutableDictionary alloc]init];
    3. [myDic setObject:[NSDictionary dictionaryWithObjectsAndKeys:@"1", @"1", nil ] forKey:@"1"];
    5. NSLog(@"%@",myDic);



    Ausgegeben wird


    {
    1 = {
    1 = 1;
    };


    Wie würde ich jetzt in den Dictionary "1" Werte hinzufügen?
    Ich hab verschiedene Sachen ausprobiert aber es will nicht klappen.
    Gruss zuko

  • Wie gesagt ich hab schon einiges ausprobiert. So würde er im Log eine Fehlermeldung ausgeben, Weil du mit [mydict objectForkey:@"1"] ein Dictionary lädst und dieser zunächst einmal immutable ist.
    Damit die Fehlermeldung verstummt muss es [[[myDic objectForKey:@"1"]mutableCopy] setObject:@"2" forKey:@"2"]; heissen aber das funktioniert nicht.

    Wenn ich im Log myDic darstelle wird der so hinzugefügten Wert nicht wiedergegeben. Es heisst weiterhin:

    {
    1 = {
    1 = 1;
    };
    Gruss zuko

  • zuko schrieb:

    So würde er im Log eine Fehlermeldung ausgeben, Weil du mit [mydict objectForkey:@"1"] ein Dictionary lädst und dieser zunächst einmal immutable ist.

    Na wenn Dir das klar ist, warum packst Du dann in myDic nicht gleich ein NSMutableDictionray rein?

    zuko schrieb:

    Damit die Fehlermeldung verstummt muss es [[[myDic objectForKey:@"1"]mutableCopy] setObject:@"2" forKey:@"2"]; heissen aber das funktioniert nicht.

    Warum sollte das auch funktionieren. Die Methode mutableCopy gibt Dir einen Zeiger auf eine Kopie zurück. Diese Kopie hat mit dem Inhalt von myDic überhaupt nichts mehr zu tun. Folglich kannst du an dieser Kopie so viel rum machen wie Du willst. Das hat keinerlei Auswirkungen auf den Inhalt von myDic.

    Michael

  • Na wahrscheinlich weil mir das doch nicht so klar ist.
    Ich dachte das erübrigt sich wenn myDic schon ein NSMutableDictionary ist.

    Mir ist letztendlich immernoch nicht klar wie ich den Wert in myDic rein bekomme!

    Wozu das ganze dient... es sollen in der Methode Informationen gesammelt werden und an richtiger stelle im Dict platziert werden.
    Gruss zuko

  • zuko schrieb:

    Ich dachte das erübrigt sich wenn myDic schon ein NSMutableDictionary ist.

    Nein, so ein Computer ist nun mal dumm. Der macht nur das, was man ihm sagt. Da ist keinerlei eigene Intelligenz vorhanden.

    zuko schrieb:

    Mir ist letztendlich immernoch nicht klar wie ich den Wert in myDic rein bekomme!

    Hab' ich doch schon gesagt. Willst Du ein Dictionary nachträglich verändern, brauchst Du ein NSMutableDictionary. Egal ob die ineinander verschachtelt sind oder nicht.

    Michael

  • Ich finde die Logik dahinter nicht offensichtlich einleuchtend.
    Wenn das übergeordnete Objekt als NSMutableDictionary definiert ist dann ist es doch logisch das man den ganzen Inhalt damit meint und alles was man reinsetzt.
    Warum die Dinge verkomplizieren? So habe ich doch ein Objekt mit verschiedenen Zugriffsmöglichkeiten. Gut...ist halt so wie es ist.

    Die Lösung ist, wie Michael schon sagte, das nicht nur das Dictionary sondern auch das Dictionary im Dictionary als mutable definiert wird.

    Quellcode

    1. NSMutableDictionary*myDic=[[NSMutableDictionary alloc]init];
    3. [myDic setObject:[NSMutableDictionary dictionaryWithObjectsAndKeys:@"1", @"1", nil ] forKey:@"1"];
    4. [[myDic objectForKey:@"1"]setObject:@"2" forKey:@"2"];
    5. NSLog(@"%@",myDic);
    Gruss zuko

  • zuko schrieb:

    Ich finde die Logik dahinter nicht offensichtlich einleuchtend.
    Wenn das übergeordnete Objekt als NSMutableDictionary definiert ist dann ist es doch logisch das man den ganzen Inhalt damit meint und alles was man reinsetzt.

    Dass man es meinen könnte ist uns vielleicht klar. Aber der Compiler verlangt Objektorientierung und Kapselung. D.h. wenn das äußere (myDic) ein NSMutableDictionary ist, heißt das nur: man kann beliebige andere Objekte nachträglich in genau dieses myDIct reinlegen oder löschen. Es ändert aber die Eigenschaften der hineingelegten Objekte nicht! Vor allem macht das aus einem ins myDict hineingelegten immutable NSDictionary kein veränderbares NSMutableDictionary.

    Schreibe mal den Code ausführlich mit Hilfsvariablen mit dem richtigen Typ. Dann sollte es klar werden.

  • hns schrieb:

    wenn das äußere (myDic) ein NSMutableDictionary ist, heißt das nur: man kann beliebige andere Objekte nachträglich in genau dieses myDIct reinlegen oder löschen. Es ändert aber die Eigenschaften der hineingelegten Objekte nicht!

    Vielleicht wird es einem klarer, wenn man bedenkt, was man alles in ein Dictionary stopfen kann: jedes beliebige Objekt.
    Arbeitete es rekursiv, würden ja plötzlich alle beinhaltenden Objekte veränderbar. Bei NSNumber, NSAttributedString oder NSManagedObject im Container wäre das Ergebnis der Veränderbarmachung sicherlich spannend.
    (zu diesen Objekten gibt es meines Wissens keine Mutable-Variante...)
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Lucas de Vil schrieb:

    zu diesen Objekten gibt es meines Wissens keine Mutable-Variante...


    Muss es ja auch nicht denn wie änderst du denn diese Objekte? Doch ganz einfach dadurch, dass du den Zeiger auf das alte Objekt wegwirfst und dir den Zeiger auf das neue Objekt holst. Hab ich zumindest so in Erinnerung.

    Bei einem NSArray ginge das nicht so leicht denn hier kannste nicht mal eben den Zeiger auf das Array wegwerfen, damit wirste ja alle Objekte im Array mit weg. Du müsstest hier mehr oder weniger kompliziert umkopieren, deshalb hat man sich hier die Mutable-Klassen einfallen lassen die dem Programmierer das Leben doch sehr erleichtern.
    [self setSignature:null];
    [[self postCount] increment];

  • Thallius schrieb:

    Mike schrieb:

    deshalb hat man sich hier die Mutable-Klassen einfallen lassen die dem Programmierer das Leben doch sehr erleichtern.

    Naja ich würde eher behaupten. Apple hat die NonMutable Klassen erfunden die es dem Programmierer schwer machen :-)

    Es ist schon eine Zumutung an den Programmierer ihm zu garantieren, dass sich die Inhalte seiner Collection nicht 'einfach so' ändern. Sehe ich auch so - nicht.
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Lucas de Vil schrieb:

    Thallius schrieb:

    Mike schrieb:

    deshalb hat man sich hier die Mutable-Klassen einfallen lassen die dem Programmierer das Leben doch sehr erleichtern.

    Naja ich würde eher behaupten. Apple hat die NonMutable Klassen erfunden die es dem Programmierer schwer machen :)

    Es ist schon eine Zumutung an den Programmierer ihm zu garantieren, dass sich die Inhalte seiner Collection nicht 'einfach so' ändern. Sehe ich auch so - nicht.

    Ich glaube kaum, dass sich eine MutableColleection "einfach so" mal eben verändert. Ich denke da muss man schon irgendwelchen Code für generieren. Ich fand es in C deutlich schlauer gelöst, das eine Variable erstmal generell mutable ist, man sie aber durch die "const" Deklaration fixieren konnte. Ich mag keine automatischen Sicherungen. Die mache ich mir lieber selber.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Naja ich würde eher behaupten. Apple hat die NonMutable Klassen erfunden die es dem Programmierer schwer machen :)


    Finde ich nicht. Den Vorteil, den ich so sehe ist schlichtweg, dass ich mir als Programmierer vorher überlegen muss, ob das Objekt später noch veränderbar sein soll oder nicht. Und wenn ich mich für Immutable entschieden habe kann ich mich später auch darauf verlassen, dass sich das Objekt nicht verändert.
    Es mag halt jeder anders, ich komm so gut klar. Ich hab aber auch nie groß was mit C++ und Co gemacht, würde sonst vielleicht auch so denken wie ihr. ;)

    Thallius schrieb:

    Ich glaube kaum, dass sich eine MutableColleection "einfach so" mal eben verändert.

    Einfach so nicht aber vielleicht verändert man sie (z.B. durch eigene Schusseligkeit) an anderer Stelle im Code und fragt sich später warum die Collection nicht so ist, wie mans erwartet. Da ist es prima wenn sie Immutable ist denn dann kann man sie nicht mehr ändern, weder bewusst noch unbewusst durch eigene Schusseligkeit ;)
    [self setSignature:null];
    [[self postCount] increment];

  • Thallius schrieb:

    Mike schrieb:

    deshalb hat man sich hier die Mutable-Klassen einfallen lassen die dem Programmierer das Leben doch sehr erleichtern.



    Naja ich würde eher behaupten. Apple hat die NonMutable Klassen erfunden die es dem Programmierer schwer machen :)

    Apple hat die nicht erfunden. Die hat vielmehr NeXT erfunden, bevor sie aufgekauft wurden. en.wikipedia.org/wiki/Cocoa_(API)#Cocoa_history

    Deshalb heißt es ja auch NSMutableDictionary.

    Der wahre Hintergrund ist vermutlich technischer Natur und nicht was dem Programmierer das Leben einfacher macht. Denn man bedenke: wir schreiben das Jahr 1988. Und haben einen 68020 mit sagenhaften 8 MByte Arbeitsspeicher. Da kommt es auf jedes Byte an. Und wenn man daher weiß, dass ein NSDictionary immutable ist, kann man (implementierungsintern) ein einfacheres Speicherschema verwenden, als wenn es mutable sein soll. D.h. da saß eines Samstags abend vor 25 Jahren ein Programmierer vor dem Problem 4 Byte einzusparen und kam dann mit einer Lösung. Wäre mal interessant, wer das war :)

    Eine ähnliche Diskussion ist ja warum es NSView + NSCell gibt. Manches (aber nicht alles) wäre eInfacher wenn es nur NSView gäbe...