Laurent Sansonetti
lsans****@apple*****
Tue Jan 9 23:43:13 JST 2007
For information to others, Hisa and I found and fixed the test unit
error (which was a Ruby 1.8.2-only problem).
Laurent
On Jan 9, 2007, at 11:46 AM, Laurent Sansonetti wrote:
> Hi Hisa,
>
> Strange, I don't get any test unit error (all tests pass). What error
> do you get exactly?
>
> Let me explain the feature demonstrated in test_direct_override.
>
> You know that now ns_import is not necessary anymore to import
> classes. This is now done automatically.
>
> However, if you did
>
> class OSX::NSView
> # ...
> end
>
> before NSView was imported, this would create a OSX::NSView class that
> directly inherits from Object (and not NSObject).
>
> Kimusa-san fixed the problem re-defining Object#inherited (in
> oc_import.rb:556). And this works.
>
> Now, in 0.10.0 there is this new feature of adding/overriding methods
> directly in classes (like Objective-C categories). Example:
>
> class OSX::NSView
> def drawRect(rect)
> # let's override the default drawRect: method
> end
> end
>
> The problem here is that the drawRect: method will be added to the
> wrong class (the one that inherits directly from Object). So I fixed
> that by re-defining Object#method_added. This just creates new methods
> in the right OSX::NSView class (it gets the unbound method objet from
> the NSView->Object class, change the class and re-bind it to NSView-
>> NSObject). And this works.
>
> The previous implementation (in 0.10.0) was unstable. Now it's working
> OK (a user tested SVN with a complex application he ported to apple-
> unstable -- that's thanks to him that all those bugs yesterday were
> discovered and fixed).
>
> Laurent
>
> On Jan 9, 2007, at 5:57 AM, Fujimoto Hisa wrote:
>
>> Hi Laurent,
>>
>> I got an error when unit testing, and then I read
>> test_direct_override
>> in test/tc_ovmix.rb little while ago:
>>
>> class OSX::DirectOverride
>> def overrideMe; 'foo' end
>> end
>> ...
>> def test_direct_override
>> assert(OSX::DirectOverride.ancestors.include?(OSX::NSObject))
>> o = OSX::DirectOverride.alloc.init
>> assert_kind_of(OSX::NSString, o.performSelector('overrideMe'))
>> end
>>
>> It seemed too complex for me as implementation viewpoint. I'm worry
>> that it may make rubycocoa really unstable more. I think the
>> following
>> feature may be better enough for us.
>>
>> class OSX::NSObject
>> def mySuperMethod; 'foo' end
>> end
>> ...
>> def test_super_method
>> o = OSX::NSString.stringWithCString('blah')
>> assert_equal('foo', o.mySuperMethod.to_s)
>> assert_equal('foo', o.performSelector('mySuperMethod').to_s)
>> end
>>
>> Maybe I can't get yet why the feature in test_direct_override is
>> needed.
>>
>> thanks
>> --
>> hisa
>>
>> On 2007/01/09, at 11:25, Laurent Sansonetti wrote:
>>
>>>
>>> On Jan 9, 2007, at 1:59 AM, Laurent Sansonetti wrote:
>>>> I also fixed some bugs reported by another user. I think that we
>>>> should make a new micro release as soon as possible, because in
>>>> those
>>>> bugs there is a very nasty one that can be seen as a regression.
>>>
>>> I also fixed a new bug.
>>>
>>> When doing
>>>
>>> class MyClass
>>> def foo
>>> # some code
>>> end
>>> end
>>>
>>> If MyClass wasn't already imported, the #foo code would be evaluated
>>> within a wrong temporary Object class. The wrapping code was a bit
>>> naive, I found a better way of wrapping the methods, but it's
>>> unfortunately using a silly hack (properly adjusting the right class
>>> to the unbound method object). I nevertheless added it in SVN, and
>>> now
>>> the problem is addressed.
>>>
>>> Example code:
>>>
>>> require 'osx/cocoa'
>>> include OSX
>>> class NSTableView
>>> def myMethod
>>> p selectedRow
>>> end
>>> end
>>> NSTableView.alloc.initWithFrame(NSZeroRect).myMethod
>>>
>>> Before exception, now the expected result (-1).
>>>
>>> Laurent
>>> _______________________________________________
>>> Rubycocoa-devel mailing list
>>> Rubyc****@lists*****
>>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
>>
>> _______________________________________________
>> Rubycocoa-devel mailing list
>> Rubyc****@lists*****
>> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel
>
> _______________________________________________
> Rubycocoa-devel mailing list
> Rubyc****@lists*****
> http://lists.sourceforge.jp/mailman/listinfo/rubycocoa-devel