Re: Modifying Set via NSArrayController breaks Set in weird way
Re: Modifying Set via NSArrayController breaks Set in weird way
- Subject: Re: Modifying Set via NSArrayController breaks Set in weird way
- From: Quincey Morris <email@hidden>
- Date: Fri, 08 Jan 2016 14:14:10 -0800
- Feedback-id: 167118m:167118agrif8a:167118sAWgWymCZt:SMTPCORP
On Jan 8, 2016, at 13:44 , Etan Kissling <email@hidden> wrote:
>
> a. Could be :-) However, since the Find feature of the minimal app stops working properly after modifying the collection, there's definitely something fishy.
I suspect the inability to display Set members comes from the fact that the debugger information says that the implementation is a Swift Set object, and the debugger isn’t capable of dealing with the situation where the actual object is a NSSet subclass**. Precisely where the bug is, is hard to say, but a bug report about the debugger seems like a good place to start.
The Xcode-hanging problem is probably a second bug. If the debugger thinks the object is a different class of object, then it may try to follow pointers, and that can take it very far afield. (After my bug report about this tendency, I was told that the debugger didn’t follow pointers for reference types by default. Apparently this meant that the 32 MB of output I attached to the bug report didn’t really exist.)
The debugger also seems to (still) have the bug where it confuses local variables that have the same name. In the method where you unwrap an optional ‘object’ into a non-optional object, it told me that ‘object’ was a view controller, at the start of the method. It turned into a Foo a couple of lines later.
So, yes, multiple fishy things. Your sample project seems like excellent supporting evidence for bug reports.
> Swift's hashValue probably forwards to ObjC's hash, but not vice versa. That's why it breaks in a strange way when I only override Swift's hashValue.
> As soon as the set is bridged to ObjC, the default hash is used and not my customized one.
After I thought about this some more, I suspect there’s no direct built-in link between ‘hash’ and ‘hashValue’. My guess is that if you use ‘==‘ it uses ‘hashValue’ for Swift objects, but that if ‘==' internally uses isEqual because the underlying objects are NSObjects, it’s going to use ‘hash’ automatically (modulo the misbehavior in the Swift bug report you mentioned).
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden