Laurent Sansonetti
lsans****@apple*****
Mon Mar 5 03:35:06 JST 2007
Hi Kimura-san, Sorry for late response. On Mar 2, 2007, at 4:36 PM, kimura wataru wrote: > Hi Laurent, > > The orverriding of RubyCocoa (called "ns_overrides" before) works > like this, as you know. > > (1) add a new IMP to the target objc class. > (2) copy the original IMP with prefix "super:" > > For example: > > class OSX::NSURL > def baseURL > super_baseURL > end > end > p OSX::NSURL.objc_instance_methods.grep(/baseURL/) > # => ["super:baseURL", "baseURL"] > > I think "super:baseURL" is unexpected. The change of r1601 > is auto-overriding to work only for classes defined Ruby world. > > * OSX::NSUserDefaults, OSX::NSURL,.. --- not override > * SomeClass < OSX::NSObject, ... --- allow override > > I make a quick patch to enable to override without "super:.." > for objc classes. This patch passed all tests. The explanation is a bit fuzzy to me, but please include the patch :) If all tests pass that's therefore OK. I think that we should also include Chris' rubycocoa_mock_problem.rb script in our test suites. > I agree the DirectOverride feature has values. Yes, we should definitely support it. Laurent On Thu, 1 Mar 2007 21:42:20 +0100, Laurent Sansonetti wrote: > >> 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: >> > < > override_only_objc_classes > .patch>_______________________________________________ > Rubycocoa-devel mailing list > Rubyc****@lists***** > http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
