[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.

-Ben

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