Dictionary mit unbestimmtem Datentyp

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Dictionary mit unbestimmtem Datentyp

    Moin,

    ja die Überschrift ist etwas verwirrend aber ich wusste nicht wie ich es sonst zusammen fassen soll.

    Ich möchte ein Dictionary definieren, weiß aber nur, das der Key vom Typ String ist.
    Value kann von Int über String bis hin zu einem weiteren Dict. alles sein.
    Nehme ich als Typ Any kann ich im Anschluss z.B. kein .count mehr auf einem enthaltenem Dict. machen.

    Ich vermute ich mache das Ganze grundlegend falsch :)
  • Meine Version:

    Quellcode

    1. var dict = [String: Any]()
    2. dict["a"] = 1
    3. dict["b"] = ["A": 1, "B": 2, "C": 3]
    4. print(dict) // ["b": ["C": 3, "B": 2, "A": 1], "a": 1]
    5. if let innerDict = dict["b"] as? Dictionary<String, Any> {
    6. print(innerDict.count) // 3
    7. }

    Explicitly unwrapped optionals, aka ! sollte man meiden, wie der Teufel das Weihwasser!
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?
  • Für Parameter-Dictionaries gibt es zwar Präzedenzfälle, aber imho sind die irgendwo zwischen "es geht halt nicht anders" und "einfach nur schlecht" einzuordnen.

    Was spricht denn dagegen, die Werte einfach in einen struct zu packen? Damit bist du dann nicht nur typsicher, sondern hast auch keine String-Konstanten mehr...
  • Zwischenergebnisse, Views, JSON (od. so ne Art davon), das passt nicht ganz zusammen. Wieso nicht eine Struktur, um die/das Datum zu kapseln?

    Passt nicht zusammen? - Ich denke mal Du hast schon Vorstellungen, wie das Zwischenergebnis definiert ist und nicht. Also welche Felder es gibt und wie das verschachtelt ist oder zusammenhängt.
  • manoh schrieb:

    Zwischenergebnisse, Views, JSON (od. so ne Art davon), das passt nicht ganz zusammen. Wieso nicht eine Struktur, um die/das Datum zu kapseln?

    Passt nicht zusammen? - Ich denke mal Du hast schon Vorstellungen, wie das Zwischenergebnis definiert ist und nicht. Also welche Felder es gibt und wie das verschachtelt ist oder zusammenhängt.

    Erlebt das struct in Swift jetzt so etwas wie eine Renaissance? In C war es damals quasi der Klassen ersatz bis das OOP erfunden wurde. Von da an waren structs sowas von verpöhnt. Jetzt wird plötzlich wieder damit geworben? Hat das einen Grund?
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)
  • Thallius schrieb:

    Erlebt das struct in Swift jetzt so etwas wie eine Renaissance?
    Ein Dreck im Vergleich zu den enums in Swift. Lies' Dir mal das entsprechende Kapitel in der Spec durch. Liest sich wie "1000 Dinge, die ich noch niemals mit enums machen wollte aber jetzt doch machen kann".

    Zurück zu den structs: In Swift sind das (mit wenigen Änderungen) im Prinzip auch Klassen. Großer Unterschied: structs werden immer mittels "call-by-value" und ein Objekt einer Klasse immer mittels "call-by-reference" behandelt.

    Thallius schrieb:

    Hat das einen Grund?
    Feuchter Traum eines Compilerbauers? Na ja, das war jetzt etwas polemisch. Es gibt tatsächlich einen Haufen Sachen, die in Swift eleganter gelöst sind.

    Nachtrag: zur eigentliche Frage: Solche Parameter-Dictionary (Arrays, Sets, was der Teufel auch immer) haben nur an zwei Stellen in einer Anwendung etwas zu suchen: 1. als Ausgabe an eine andere Schnittstelle, die sowas eben benötigt. 2. Als Eingabe einer anderen Schnittstelle. Als Beispiel dafür fallen mir z.B. Requests/Response eines zu verwendenden WebService ein (Also JSON, XML-RPC, SOAP). So ein Dict wird dann ratz-fatz in eine Struktur/Objekt einer Klasse gewandelt und anschließend wird nur noch das verwendet.
  • gandhi schrieb:

    Thallius schrieb:

    Erlebt das struct in Swift jetzt so etwas wie eine Renaissance?
    Ein Dreck im Vergleich zu den enums in Swift. Lies' Dir mal das entsprechende Kapitel in der Spec durch. Liest sich wie "1000 Dinge, die ich noch niemals mit enums machen wollte aber jetzt doch machen kann".
    Das ist wie mit den Smartphones: "1000 Dinge, die man nie mit einem Telephon machen wollte, aber jetzt machen kann."
    Das zweitwichtigste Telephon-Feature gibt es dann bei den heutigen iPhones und Co. übrigens immer ncoch nicht: Das gekringelte Kabel am Hörer, mit dem man beim Telephonieren spielen konnte und sich um den Finger wickeln konnte! :D

    Ich für meinen Teil begrüße es normalerweise, wenn neue Entwicklungen neue Möglichkeiten bieten.
    Das iPhone sagt: "Zum Antworten streichen". Wie? Echt Jetzt? Muß ich erst die Wohnung streichen!?