[MacRuby-devel] next release

Benjamin Stiglitz ben at tanjero.com
Fri Mar 14 00:12:50 PDT 2008

Gteat example. Maybe we can treat the immutable strings as frozen-- 
that sounds nice and clean.


On Mar 13, 2008, at 11:09 PM, Laurent Sansonetti  
<lsansonetti at apple.com> wrote:

> On Mar 13, 2008, at 10:56 PM, Satoshi Nakagawa wrote:
>> On 2008/03/14, at 13:53, Laurent Sansonetti wrote:
>>>>> Say that you receive a non-mutable string from Objective-C, and  
>>>>> want to call the #upcase! method on it. AFAIK, MacRuby could 1)  
>>>>> raise an exception 2) auto-convert the receiver as mutable (but  
>>>>> a new object will likely have to be created).
>>>> There's no way to do this switch in the general case of incoming  
>>>> CFTypes. Can we easily fudge the locals table to point to a new  
>>>> object in YARV?
>>> Yes we most probably can, but the real question is, should we? I  
>>> personally have a preference for 1), which is more consistent with  
>>> the underlying APIs. Mmh.
>> I would support 1).  Because of consistency.
>> For example,
>> defaults = NSUserDefaults.standardUserDefaults
>> defaults.objectForKey('key').upcase!
>> It is intended to replace a string in the user defaults with upcase  
>> one. With auto-conversion, it would seem to work at a glance. But  
>> it won't change the string in the user defaults.
>> Isn't it confusing?
> Excellent sample, indeed. Modifications to the auto-converted object  
> won't be reflected in the previous object.
> I think we can live with 1), especially since it's very  
> straightforward to work around by using a non-destructive method or  
> creating a mutable copy. And all objects created from Ruby will be  
> mutable anyway, so from a pure Ruby perspective there will not be  
> any difference with the current implementation.
> Laurent

More information about the MacRuby-devel mailing list