IKit diff document によると、ios9/Swift 2
var text: String!
になった var text: String?
ITextFieldのドキュメント によれば、
This string is @"" by default.
この変更の目的がわかりません。テキストフィールドが存在する場合、そのプロパティは常に空の文字列ではありませんか?このフィールドはどの時点で空の文字列を返しますか?ユーザーがそれと対話したら?ビュー階層に追加されたら?どの時点でnil
を返しますか?
テキストフィールドが最初に存在する場合、テキストプロパティも存在すると仮定しても常に安全ですか?これは、多くの検索/置換につながるようです.text
から.text!
私はそれがドキュメントで言及されている場所を見ていないので、おそらく誰かがいくつかのバックストーリーを持っているか、これが変わった理由について助けてくれます。
要するに、(タイトルへの回答)そうではなかった。
詳細に:
私にとっては、強制的にアンラップされないオプションとしてそれを持っている方がはるかに理にかなっています。 Appleは、開発者にoptional!
を決して使用しないように促しています。また、同じルールをAPIに適用することは理にかなっています。
この理由は、nilになる可能性があり、コードを実行するために?
または!
で宣言されても違いはないからです。 !
を使用すると、特にAPIコードに関しては、実際に便利なXcodeの警告が削除されます。あなたがそれが実際にオプションであることに気付いていないなら、あなたはただトラブルを求めているだけです。
guard
を使用してnilをチェックすることもはるかに優れており、""
をチェックすることでこれを連鎖させることができます。
一般に、nilであるものはメモリを使用していないため、オプションの方が優れています。オプションが増えれば増えるほど、アプリを軽くすることができます。また、見た目も悪くなく、Doomのピラミッドに追加されません。
この例では、両方の文字列を引数として使用し、funcパラメータの?
を削除すると、Xcodeが警告を表示します。
この部分に直接答えるのを忘れた: Nilに設定するとnilになります。これは、メモリを少し節約するために行うことができます。 nilに設定するオプションがあり、xcodeが適切に処理するように警告しないのは意味がありません。 =>これは不可能です...
var forcedUnwrappedString : String! = ""
var optionalString : String? = ""
forcedUnwrappedString = nil
optionalString = nil
func doSomethingWithString(string : String?) -> String? {
guard var unwrappedString = string else {
// error handling here
return nil
}
let tempString = unwrappedString + "!"
return tempString
}
func doSomethingUnsafeWithString(string : String) -> String {
let tempString = string
return tempString
}
var newString = doSomethingWithString(optionalString)
var newString2 = doSomethingWithString(forcedUnwrappedString)
newString = doSomethingUnsafeWithString(optionalString!) // this will crash without a warning fro xcode
newString2 = doSomethingUnsafeWithString(forcedUnwrappedString) // this will crash without a warning fro xcode
更新:
UITextfield
のtextプロパティには、nil
の場合は常に""
に設定するセッターがあり、ドキュメントまたはUIKit .hファイルのどこにもこれに関する情報はありません。
var textField = UITextField(frame: CGRect(x: 0, y: 0, width: 0, height: 0))
var string = textField.text // string = ""
textField.text = nil
string = textField.text // string = ""
この問題を回避する簡単な方法は、UITextFieldの拡張機能を作成し、.textプロパティの代わりにそれを使用することです。
extension UITextField {
var unwrappedText: String {
return self.text ?? ""
}
}
これで、オプションを気にせずにtextfield.unwrappedTextと言うことができます。 (もちろん、これは値を読み取るためだけです)。
メンケが言ったように、text
をnilに設定することは実際に不可能です。明らかにAppleは、現在の実装にもかかわらず、null可能として文書化することを望んでおり、私には意味がありません-私には十分な意味がないことを意味します。 Appleを決定するのは間違いではありませんが、誰にとってもエレガントな方法ですか?明らかにそうではありません。あなたがそれらに同意しなくても心配しないでください。 、Appleのいくつかの決定について意見を保留しても大丈夫です。
この変更の目的は何ですか?多分彼らはUIKitsコンポーネントのプロパティを決して一貫性の問題のためにnull不可にしないという内部ルールを始めました。理論的には、極端な場合にはメモリのプレッシャーが原因でテキストプロパティが解放される可能性があると考えています。それらが何であれ、私はそれらが有効であるとは思わないが、我々は従わなければならない。しかし、これは私をファンボーイにするものではありません。