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@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