Optional<AnyObject> Typ bekommen

prettygirl · 1. Mai 2016, 13:54

hallo meine lieben,
ich bekomme beim auslesen einer Datei den wert Optional(1) in der variable datei1
Mache ich dann

Quellcode

print(mirror(reflecting: test))

erhalte ich "Optional<AnyObject>". Wenn ich hingegen direkt

Quellcode

print(mirror(reflecting: Optional(1)))

mache, erhalte ich "Optional<Int>". Da der ausgelesene Wert sowohl, Strings, Zahlen und wahrheitswerte sein kann, weiß ich nicht, wie ich test nun auf die verschiedenen fälle überprüfen kann

danke

torquato · 1. Mai 2016, 16:51

conditional Casting mit as?.

Beispiel:

C-Quellcode

var array = [Any]()
array.append("foo")
array.append(1)
for x in array {
if let value = x as? String {
print(value + "bar")
}
else if let value = x as? Int {
print(value * 5)
}
}

Alles anzeigen

prettygirl · 1. Mai 2016, 17:18

danke dir, das funktioniert schon besser, einziges problem sind jetzt noch zahlen und wahrheitswerte. Je nach dem, welches vorher in der if-Bedingung auftaucht, wird es als zahl oder bool markiert.
also wenn ich halt x = 54 oder x = 1 hab, und bool früher als int in der if-abfrage steht, bekomme ich true zurück.
andersrum ist es dann halt genau, nur andersrum.

wie kann man das jetzt noch besser "filtern"?

torquato · 1. Mai 2016, 17:33

O.g. Beispiel um Boolean-Werte ergänzt:

C-Quellcode

var array = [Any]()
array.append("foo")
array.append(false)
array.append(1)
for x in array {
if let value = x as? String {
print(value + "bar")
}
else if let value = x as? Bool {
print(value)
}
else if let value = x as? Int {
print(value * 5)
}
}

Alles anzeigen

Funktioniert problemlos und ergibt folgenden Output:

Quellcode

foobar
false
5

Das Problem liegt also schon vorher an Deiner Datei, bzw. wie die geparsed wird. Was machst Du denn, um die Datei auszulesen?

AppleDeveloper · 1. Mai 2016, 17:43

Ich habe keine große Ahnung von Swift aber wenn die Zahl jetzt 1 oder 0 heißt wird es dann nicht als Bool interpretiert?

Wenn ich in Obiective C eine NSNumber zu Boolean konvertiere und die hat den Wert 0 oder 1 ist das auch ein gültiger Boolean.

torquato · 1. Mai 2016, 17:55

AppleDeveloper schrieb:

Ich habe keine große Ahnung von Swift aber wenn die Zahl jetzt 1 oder 0 heißt wird es dann nicht als Bool interpretiert?

In Swift selbst sind Boolean- und Intereger-Werte vollkommen unterschiedliche Datentypen. Die können noch nicht mal zwangsweise hin- und hergecastet werden!

Trotzdem. Ich vermute auch, daß beim Auslesen der Datei irgendetwas in der Richtung passiert...

prettygirl · 1. Mai 2016, 18:15

torquato schrieb:

[...]

Das Problem liegt also schon vorher an Deiner Datei, bzw. wie die geparsed wird. Was machst Du denn, um die Datei auszulesen?

torquato schrieb:

[...]

Trotzdem. Ich vermute auch, daß beim Auslesen der Datei irgendetwas in der Richtung passiert...

Ja, richtig vermutet, also ich lese ein plist-datei aus und speichere sie in einem dic. Wenn ich das ausgelesene Objekt nun x zuweise, wird x zu einem Optional und dem ausgelesenen Wert, also zum Beispiel Optional(5). In diesem Fall greift dann dein code auch nicht, weil ein Downcast stattfinden muss (steht so bei Xcode), nach dem x muss dafür ein Ausrufezeichen stehen, also sowas wie "value = x! as? Bool".

Jetzt habe ich quasi folgendes

Quellcode

let x = dict.ObjectForKey("test")
if let value = x! as? String {
print(value + "bar")
}
else if let value = x! as? Bool {
print(value)
}
else if let value = x! as? Int {
print(value * 5)
}

Wird aus "test" ein String ausgelesen, klappt alles. Wird aber eine zahl ausgelesen, wird, wenn sie größer als 0 ist, true zurückgegeben. Bei einem bool auch (je nach dem, ob true/false). Steht zuerst die Überprüfung aus eine zahl in der reihe, wird bei einer zahl logischerweise die zahl ausgegeben, bei einem boolean aber auch (also entweder 0 oder 1).

Der code wird übrigens benötigt, um falsche Modifikationen zu erkennen und einen Programmfehler zu vermeiden.

torquato · 1. Mai 2016, 18:59

Erstmal eine Bemerkung nicht direkt zu Deinem Problem.
Explicitly unwrapped optionals, also die, besonders bei Anfängern immer sehr beliebten Ausrufezeichen (

), sind idR zu 99 Prozent falscher Code, mit dem man sagt, daß man sich ins Knie schießen will. Es gibt nur ganz wenige vereinzelte Fälle, in denen man die benutzen sollte.

Meide in Swift das ! wie der Teufel das Weihwasser!

Dein Code

Quellcode

let x = dict.ObjectForKey("test")
if let value = x! as? String {
print(value + "bar")
}

sollte in Swift folgendermaßen aussehen:

Quellcode

if let x = dict["test"] {
if let value = x as? String {
print(value + "bar")
}

In Swift greift man üblicherweise auch nicht über objectForKey auf die Elemente eines Dictionarys zu.^^

Ich vermute, daß Du via NSProperyListSerialization die plist ausliest. In Cocoa werden da Boolean-Werte als NSNumber übergeben. Ich verfmute, daß da bei Dir der Hase im Pfeffer begraben liegt. Da kann ich spontan keine Lösung bieten. Da muß jemand anderes einschreiten.

prettygirl · 1. Mai 2016, 19:41

torquato schrieb:

Erstmal eine Bemerkung nicht direkt zu Deinem Problem.
Explicitly unwrapped optionals, also die, besonders bei Anfängern immer sehr beliebten Ausrufezeichen ( ), sind idR zu 99 Prozent falscher Code, mit dem man sagt, daß man sich ins Knie schießen will. Es gibt nur ganz wenige vereinzelte Fälle, in denen man die benutzen sollte.

Meide in Swift das ! wie der Teufel das Weihwasser!

[...]

Quellcode

if let x = dict["test"] {

if let value = x as? String {

print(value + "bar")

}

In Swift greift man üblicherweise auch nicht über objectForKey auf die Elemente eines Dictionarys zu.^^

[...]

Also, bei vielen meiner Funktionen schlägt mir Xcode im return das Ausrufezeichen vor, wie löse ich das denn jetzt "richtig"?

Okay, das wusste ich nicht, gibt es dafür einen speziellen Grund, dass man zum Auslesen nicht objectForKey nimmt?

torquato · 1. Mai 2016, 20:23

prettygirl schrieb:

Also, bei vielen meiner Funktionen schlägt mir Xcode im return das Ausrufezeichen vor, wie löse ich das denn jetzt "richtig"?

Man sollte nicht alles glauben, was Xcode einem sagt.

Kann ich so spontan im 'Blindflug' nicht sagen. Ich vermute, daß Du das Prinzip Optionals in Swift noch nicht so ganz verstehst und deshalb in solche Compilermeldungen gerätst.

Poste doch einfach mal so einen Fall. Vielleicht kann ich (oder jemand anders) dann was dazu sagen.

prettygirl schrieb:

Okay, das wusste ich nicht, gibt es dafür einen speziellen Grund, dass man zum Auslesen nicht objectForKey nimmt?

Du kanst natürlich auch objectForKey nehmen. Das ist keine Frage.

objectForKey ist eine Methode von NSDictionary. Das ist Foundation API aus Objective-C heraus geboren. Swift hat von Haus aus den Typ Dictionary (ohne NS) eingebaut. Dieser Swift-Typ hat diese Methode objectForKey eigentlich gar nicht, sondern greift von Haus aus über Subscripts auf die Elemente zu, einfach der von der Sprachsyntax her vorgesehene Weg in Swift.

Mischt man beides, wird zwischen dem Foundation NSDictionary und dem Swift Dictionary unter der Haube eine Brücke gebaut, so daß auch ein Swift-Dictionary plötzlich damit umgehen kann. Davon kriegt man in der Regel gar nichts mit und es ist auch nicht weiter schlimm.

Da Du in Swift schreibst, wollte ich lediglich darauf hinweisen, daß Swift da eigene Möglichkeite hat, die man normalerweise nimmt, statt auf die Foundation API zurückzugreifen.

Aber, wie gesagt: objectForKey ist vollkommen legitim.

torquato · 1. Mai 2016, 22:05

prettygirl schrieb:

gibt es dafür einen speziellen Grund, dass man zum Auslesen nicht objectForKey nimmt?

Noch eine launige Randbemerkung dazu.

In Swift 3 (geplant für Ende 2016. Ich gehe von Anfang 2017 aus) wird es in Zukunft dict.object(forKey: "test") heißen anstatt dict.objectForKey("test"). Da hat ein ganzer Kindergarten von hochintellinenten Programmierern monatelang drüber diskutiert, und ich habe bis heute nicht verstanden, was die gestochen hat oder was die geraucht haben....

Mit dict["test"] ist man einfach heute schon auf der sicheren Seite.

Michael · 1. Mai 2016, 22:19

torquato schrieb:

objectForKey ist eine Methode von NSDictionary. Das ist Foundation API aus Objective-C heraus geboren.

Nur als Ergänzung: auch in Objective-C kann man schon eine Weile per Subscript auf die Inhalte eines NSDictionary zugreifen.

torquato schrieb:

Swift hat von Haus aus den Typ Dictionary (ohne NS) eingebaut. Dieser Swift-Typ hat diese Methode objectForKey eigentlich gar nicht, sondern greift von Haus aus über Subscripts auf die Elemente zu, einfach der von der Sprachsyntax her vorgesehene Weg in Swift.

Nur wissen wir gar nicht, ob wir es überhaupt mit einem Swift Dictionary zu tun haben oder ob das Einlesen der Plist ein NSDictionary liefert.

torquato · 1. Mai 2016, 22:47

Michael schrieb:

torquato schrieb:

objectForKey ist eine Methode von NSDictionary. Das ist Foundation API aus Objective-C heraus geboren.

Nur als Ergänzung: auch in Objective-C kann man schon eine Weile per Subscript auf die Inhalte eines NSDictionary zugreifen.

Ja. Stimmt natürlich.^^
Ich habe sehr (seeeehr!) lange nicht mehr was in Objective-C gemacht.

Eine frühere Änderung in Objective-C hat also schon mal ein Feature in Swift vorweggenommen.

Michael schrieb:

torquato schrieb:

Swift hat von Haus aus den Typ Dictionary (ohne NS) eingebaut. Dieser Swift-Typ hat diese Methode objectForKey eigentlich gar nicht, sondern greift von Haus aus über Subscripts auf die Elemente zu, einfach der von der Sprachsyntax her vorgesehene Weg in Swift.

Nur wissen wir gar nicht, ob wir es überhaupt mit einem Swift Dictionary zu tun haben oder ob das Einlesen der Plist ein NSDictionary liefert.

Wenn, wie ich vermute, die plist mit NSProperyListSerialization ausgelesen wird, kommt bestimmt ein NSDictionary raus. Das ist aber nicht der Punkt. Wenn man sich innerhalb einer Sprache befindet, sollte man doch üblicherweise auch, nach Möglichkeit innerhab der Sprachsyntax bleiben, oder nicht?

Michael · 2. Mai 2016, 01:45

torquato schrieb:

Wenn man sich innerhalb einer Sprache befindet, sollte man doch üblicherweise auch, nach Möglichkeit innerhab der Sprachsyntax bleiben, oder nicht?

Ja, natürlich. Allerdings dict.objectForKey("foo") ist Swift Syntax. In Objective-C Syntax sieht das so aus: [dict objectForKey:@"foo"];.

torquato · 2. Mai 2016, 16:05

Klugscheißer!^^

prettygirl · 2. Mai 2016, 17:58

Danke, habe es jetzt das objectForKey ersetzt

torquato schrieb:

prettygirl schrieb:

Also, bei vielen meiner Funktionen schlägt mir Xcode im return das Ausrufezeichen vor, wie löse ich das denn jetzt "richtig"?

Man sollte nicht alles glauben, was Xcode einem sagt.

Kann ich so spontan im 'Blindflug' nicht sagen. Ich vermute, daß Du das Prinzip Optionals in Swift noch nicht so ganz verstehst und deshalb in solche Compilermeldungen gerätst.

Poste doch einfach mal so einen Fall. Vielleicht kann ich (oder jemand anders) dann was dazu sagen.

[...]

Ganz allgemein gesagt, als Beispiel ...

Quellcode

func test(test: Int) -> Int {
var newtest: Int?
if (test >= 0) {
newtest = test
} else {
newtest = 1
}
return newtest!
}

gritsch · 2. Mai 2016, 18:02

gib newtest doch gleich den initalen wert 1 dann sparst du dir das else und vor allem das ? und !

torquato · 2. Mai 2016, 18:22

Abgesehen, von dem Shortcut den @gritsch genannt hat...

Wenn eine Variable 'newtest' gar nicht nil sein kann und soll, dann deklariert man sie erst gar nicht als Optional. Einfach statt var newtest: Int? var newtest: Int und man erspart sich die Frage- und Ausrufezeichen.

Ich vermute mal, Du hast irgendwo im Netz in einem Tutorial oder so etwas wie var newtest: Int? gesehen und verwendest das jetzt, hast aber nicht so recht verstanden, was das Fragezeichen eigentlich bezwecken soll... *schulterzuck*

torquato · 2. Mai 2016, 20:00

Noch eine kleine Lappalie, die ich, glaube ich, hier im Forum schon mal an anderer Stelle erwähnt habe.

prettygirl schrieb:

Quellcode

if (test >= 0) {

In C und Derivaten sind mW die runden Klammern bei solchen if-Abfragen zwingend. In Swift kann, ja sollte man sogar besser auf diese Klammern verzichten.

In der Swift-'community' besteht der überwiegende Konsens, daß solche sprachlich nicht notwendigen Klammern möglichst nicht gesetzt werden. Sie erhöhen nur das Buchstaben-Grundrauschen im Code, haben aber keine eigene Funktion...

gritsch · 2. Mai 2016, 20:03

torquato schrieb:

Noch eine kleine Lappalie, die ich, glaube ich, hier im Forum schon mal an anderer Stelle erwähnt habe.

prettygirl schrieb:

Quellcode

if (test >= 0) {

In C und Derivaten sind mW die runden Klammern bei solchen if-Abfragen zwingend. In Swift kann, ja sollte man sogar besser auf diese Klammern verzichten.

In der Swift-'community' besteht der überwiegende Konsens, daß solche sprachlich nicht notwendigen Klammern möglichst nicht gesetzt werden. Sie erhöhen nur das Buchstaben-Grundrauschen im Code, haben aber keine eigene Funktion...

Wenn das wirklich so sein sollte dann spinnen die doch komplett.
Auch wenn es nicht nötig ist, hilft es doch ungemein den code verständlicher zu machen und das ist das ALLERWICHTIGSTE!