Laurent Sansonetti
lsans****@apple*****
Fri Mar 2 05:42:20 JST 2007
Kimura-san, I reverted the r1601 change because as you noticed it breaks the DirectOverride feature. Doing: class OSX::SomeClass def someMethod end end was failing if OSX::SomeClass hasn't been imported yet. One test was therefore failing, as well as an application (internal) that was using it. I investigated Chris' bug reproducer and it seems that a solution would be to intercept #remove_method and restore the original Objective-C method there? Laurent On Feb 27, 2007, at 11:11 PM, kimura wataru wrote: > Hi, > > I commited this fix as r1601. Please check out the latest revision. > > Then, test script reports 1 failure: > 1) Failure: > test_direct_override(TC_OVMIX) [./tc_ovmix.rb:124]: > <nil> > expected to be kind_of? > <OSX::NSString> but was > <NilClass>. > > I think this test case must fail. The class DirectOverride defined > in Objective-C world. If we expect RubyCocoa to auto-override methods > for Objective-C classes, the following change of oc_import.rb is > needed. > > * remove checking objc-class or ruby-class at > NSBehaviorAttachment#_ns_enable_override? > > But I recognize to expect auto-overriding for objc classes. I'll try > to make a patch for this change and some enhancement. > > On Tue, 27 Feb 2007 18:13:08 +0000, Chris Mcgrath wrote: >> On 27 Feb 2007, at 15:05, kimura wataru wrote: >> >> >>> >> >>> This behavior is a bug of RubyCocoa. RubyCocoa shold NOT treat a >> >>> metaclass of Cocoa classes as a subclass of Cocoa classes. I think >> >>> we can fix the problem soon. >> >> Great! :) Let me know if there is anything I can help with. >> >> Cheers, >> >> Chris > > > -- > kimura wataru > _______________________________________________ > Rubycocoa-devel mailing list > Rubyc****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
