Brian Marick
maric****@examp*****
Fri Apr 24 23:31:36 JST 2009
On Apr 23, 2009, at 11:58 PM, Allison Newman wrote: > For the first part, I'm not sure that you are right Brian. The == > operator should be passed to the encapsulated Obj-C objects, and in > the case you gave, this should always be the same object, even if > there are two seperate ruby proxies. Sorry, I mistyped. I meant to say that this: a[0].object_id == a[0].object_id can sometimes be false. That's what the test program shows. > > 1) It's always the classes that have automatic translations from ruby > to Obj-C that fail (String, Array, Hash, etc). Cocoa-specific class > such as NSView don't have any problems NSManagedObjects (created when Core Data objects are fetched from disk) do fail, but - in the case that led me down the path to this mail - don't fail until after something like 17 extractions from an NSArray. But it would take a bigger program to show that. > 2) If you remove the to_ns in make_array, everything works just fine. Yes. In that case, each array element has a pointer to it from "the Ruby universe", so each of their Ruby proxies / Ruby halves stays around to be returned by each(). The to_ns makes the array elements have no Ruby objects pointing to them. So RubyCoca [I believe] can create a new proxy each time each() returns a particular Objective-C object. I was making a screencast about how all this led to a crash bug in an app, by way of explaining the issue to others. Here: http://www.exampler.com/tmp/cocoapuffs1c.mov My animation of how the different objects and proxies work is at 2:32 to 2:56. I didn't make an animation for the more complicated case of an NSArray yet because I wanted a simpler example of the issue. It was when making it that I discovered the inconsistent failures. > > 3) the to_ruby call actually has no impact on the test, it can be > safely removed, simplifying the test system a bit. Yes. That's just to make the output like this: [3078130] instead of like this: #<NSCFArray [#<NSCFNumber 3078130 >]> ----- Brian Marick, independent consultant Mostly on agile methods with a testing slant www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
