Allison Newman
demal****@mac*****
Fri Apr 24 13:58:45 JST 2009
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. I may of course be completely
wrong about that, but that's my understanding of how the bridge works.
For the second I don't have any answers, but I have a few observations/
suppositions:
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
2) If you remove the to_ns in make_array, everything works just fine.
3) the to_ruby call actually has no impact on the test, it can be
safely removed, simplifying the test system a bit.
Based on those observations, if I had to guess, I'd say that somehow
the automatic type conversion has a bug in it, hence inconsistant
behaviour.
I have to go get ready for work, so I'll leave it to others to finish
up the sleuthing :-)
Alli
Le 23 avr. 09 à 23:44, Brian Marick a écrit :
> Suppose you have an NSArray containing some Objective-C objects. I
> understand why the following can be false:
>
> array[0] == array[0]
>
> Each time the element is extracted from the array, it could get a new
> "ruby half". The main point of this note is to confirm that's correct
> behavior.
>
> The lesser part of the note: I don't understand why the behavior isn't
> consistent. Consider this program:
>
> #! /usr/bin/env ruby
> require 'osx/cocoa'
> include OSX
>
> def run(klass, count)
> array = make_array(klass, count)
> first = collect_the_object_ids(array)
> second = collect_the_object_ids(array)
> if first == second
> puts "success"
> else
> puts "FAILURE for #{klass.name}"
> puts first[0,10].inspect
> puts second[0,10].inspect
> end
> end
>
> def make_array(klass, count)
> (0...count).collect {
> klass.alloc.init
> }.to_ns
> end
>
> def collect_the_object_ids(array)
> array.collect { | e | e.object_id }.to_ruby
> end
>
>
> run(NSDictionary, 1)
> run(NSString, 1)
> run(NSTextField, 100000)
>
>
> It consistently produces these results:
>
> FAILURE for OSX::NSDictionary
> [3079050]
> [3078130]
> FAILURE for OSX::NSString
> [3077490]
> [3077260]
> success
>
> An NSManagedObject in a 16 element NSArray had a stable object_id the
> first 17 times it was extracted, then it changed.
>
> There's caching going on in some cases. What are the rules behind
> them? Thanks.
>
> -----
> Brian Marick, independent consultant
> Mostly on agile methods with a testing slant
> www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
>
> _______________________________________________
> Rubycocoa-devel mailing list
> Rubyc****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel