[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