[MacRuby-devel] next release

[Laurent Sansonetti]

I was wondering the same thing last night, but then... how to  
implement the concept of "frozen object" in pure CFStrings (and  
CFArrays, CFDictionary), without subclassing them?

s = "foo"
s.freeze

Maybe there is a flag that we can use in the internal cftype. But it  
already sounds evil.

Laurent

On Mar 14, 2008, at 12:12 AM, Benjamin Stiglitz wrote:

> 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