その1では、keyにNSMutableStringを入れて中身を変更しようとして失敗したのだけど、もっと単純なカスタムクラスを使ってしまえば実体がどうのこうのって話を回避することができるのではないか?と考えた。いうわけでkeyにするためのクラスを新たに作ってみることにした。単純にint型変数を持つだけのクラス。2488343994)ぬぁ、落ちた!!"copyWithZone:"というメソッドが勝手に送られているらしい。そんなものは実装していない。リファレンスを読んでみると、そこら中に「keyにはNSCopyingProtocolをconformしろ」と書いてある。ReferenceどうやらNSDictionaryに格納される際にkeyはコピーされたものが使われるらしい。いうわけで以下のページを参考にしつつNSCopyingプロトコルを採用してMyClassを変更。hoge;}よし、エラーは起こらなくなった。見にくいのでdescriptionをオーバーライドしてみよう。あとallKeysの内容を確認してみる。MyClassうん、やっぱり違うインスタンスたちが格納されているな。格納されるときにcopyWithZoneの結果を入れているっていうことか〜。言え、それぞれの中の値は変更できるようにしてしまえば変更できるはず。orz中に4が入っているからと言って、dict内に入っているキーたちと一致しているとは見なされないらしい。isEqual:).」という記述が。object:hogeなんと!?piyoが消えたwwwwwwもうこうなってくると挙動が読めない。object:fugaと、しっかり得ることが出来てしまう。何にせよ、NSDictionaryのエントリーそのものがkeyの重複によって消えてしまうようなことはないようだ。うーん、結局結論が無い、というかよく分からないことになってしまった。こんなワケの分からない操作を実際のアプリでするワケはないか。こんなことができて、こういうことが起こる、というお話、とまとめよう。『自分で作成したクラスを使えば、キーの重複のようなことを起こすことはできる。その際のNSDictionaryの挙動はよく分からなくなる。