[Rubycocoa-devel 283] Re: new 'unstable' branch

Back to archive index

Laurent Sansonetti lsans****@apple*****
Thu Jun 8 09:28:02 JST 2006


Hi Jonathan,

On Jun 7, 2006, at 11:35 PM, Jonathan Paisley wrote:

>> Ah yes, this is a known-issue. The NSOutlineView datasource model  
>> expects this, so I think this should be done at the application  
>> level, either using that NSOutlineViewable module you wrote or  
>> explicitly make sure the Ruby proxies are 'retained'.
>
> Yep, I agree with that. I hadn't intended to give the impression  
> that I thought it was a bug in NSOutlineView - just a bit of a pain  
> sometimes! :)
>

Haha, I completely understand your frustration :-)

>> Sorry I did not understand what you mean with "automatic support  
>> for dereferencing the proxy when it comes in as an argument to a  
>> ruby method", could you elaborate a bit more?
>
> Yep (I realise that wasn't very clear):
>
> The NSOutlineViewable module overrides/implements 'to_nsobj' which  
> creates an NSObject slave for the Ruby data model object.  
> Therefore, the conversion from Ruby object to slave is transparent  
> (since RubyCocoa core uses 'to_nsobj').
>
> However, conversion back requires accessing the 'slave' attribute.  
> The "automatic support" I was talking about would notice the proxy  
> object when constructing the ruby arguments from an objc method  
> invocation and pass through the slave instead of the proxy. Then,  
> to the user, it would be fully transparent after
>
> Since writing that code I've decided that the 'ObjectSpace._id2ref'  
> stuff is unnecessary.
>

I understand now, thanks for the explanation.

>> # I have an idea on how to fix this at the Ruby interpreter level,  
>> which should be elegant and would allow us to not use proxies  
>> anymore, but this requires some work.
>
> Can you indicate the rough approach you were thinking of?

The idea would be to add a new field in the basic Ruby object  
structure to be able to store a kind-of isa pointer to the Objective- 
C object instance it wraps in the Objective-C world. For example, in  
the case of that REXML::Element it would link to that new RBObject  
proxy, and this would fix this special issue as the RBObject proxy  
object would live the same time than the REXML::Element object.

And of course, this would make costless Ruby -> Objective-C bridge  
conversions.

But doing this on the other side would not be possible without  
changing the ObjC runtime, to be able to store the associated VALUE  
Ruby pointer within the Objective-C object structure. One thing we  
could do is hooking the allocation routine to allocate a supplement  
of 4 bytes per new object where we can store the information.

Anyway this is pure speculation without any investigation... when I  
will have some time I will try to start looking at this more  
seriously ;-)

Laurent



More information about the Rubycocoa-devel mailing list
Back to archive index