On Mar 13, 2008, at 4:49 PM, Ernest Prabhakar wrote:
Hi Laurent,
On Mar 13, 2008, at 4:17 PM, Laurent Sansonetti wrote:
As we’ve discussed offline, I’d still love to take a crack at this one. I do wonder what we’ll do with NSStrings, though, since they’re not actually mutable. So many issues.
We could check for mutability and accordingly raise exceptions in ! methods. Every string created by Ruby would be mutable anyway, we are only talking about non-mutable NSStrings received from ObjC, which I don't think are a big deal. But if we want to be truly compatible on the other side too... we will have to find a solution.
Could we add a category on NSString that auto-converts it to an NSMutableString when necessary?
Well there is already [-mutableCopy] which when called on an NSString returns an NSMutableString. But you have to call it, the process is not done automatically for you. 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). Laurent
Could we add a category on NSString that auto-converts it to an NSMutableString when necessary?
Well there is already [-mutableCopy] which when called on an NSString returns an NSMutableString. But you have to call it, the process is not done automatically for you.
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? -Bem
On Mar 13, 2008, at 6:05 PM, Benjamin Stiglitz wrote:
Could we add a category on NSString that auto-converts it to an NSMutableString when necessary?
Well there is already [-mutableCopy] which when called on an NSString returns an NSMutableString. But you have to call it, the process is not done automatically for you.
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. Laurent
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? -- Satoshi Nakagawa
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
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
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@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
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.
Definitely a great example, you convinced me immediately. So at least one user votes "yeah, throw an exception". I suggest though that: 1. Make a wiki entry about the issue. 2. Put link to wiki entry in the exception. But that's just me because I get tired of Googling for every exception so I can figure out what it means... Pierce
participants (4)
-
Benjamin Stiglitz
-
Laurent Sansonetti
-
Pierce T. Wetter III
-
Satoshi Nakagawa