Re: [Pyobjc-dev] NSString & mutability

[Ronald O. <ous...@ci...>]

On Tuesday, Feb 4, 2003, at 21:56 Europe/Amsterdam, Just van Rossum 
wrote:

> bb...@ma... wrote:
>
>> Nice hack, but....
>>
>> What about all the code that might return a mutable string depending
>> on how the developer exercises the API?  Are you willing to assume
>> that every getter and setter that internally makes a immutable copy
>> of the set string value?  i.e. that...
>>
>> .... [fooObject setMyNameIs: someRandomMutableString]; return
>> [fooObject myNameIs] ....
>>
>> .... that -myNameIs will return an immutable string?
>
> I'm totally willing to accept a surprise like that. I don't even see 
> the
> problem when using such an API from Python: you call
> fooObject.setMyNameIs_() with a Python string, you call myNameIs() and
> get a Python string. Same string, different id. No problem in Python.
>
> Can you please give an example of an _actual_ problem? I'll have a go
> myself:
>
> Let's assume the API does the reverse: it takes an immutable string, 
> yet
> returns its internal mutable copy, although myNameIs is declared to
> return an NSString. Now there _is_ a surprise: instead of a 100%
> equivalent string we get an NSMutableString instance. Ok, a surprise,
> but is it so bad? If the object internally uses a mutable string, it's
> likely that this is clear from the nature of the object (eg. it's some
> sort of editor for the string). So I still think such a surprise will 
> be
> rare.

The 'scary' part is that the behavious could change without notice from 
one update of MacOS to the other, because NSMutableString is a subclass 
of NSString switching from a returnvalue of type NSString to one of 
NSMutableString is a backward compatible change.

>
>> See this message -- it is still quite relevant.  Mike Ferris is one
>> of the guys who helped write the AppKit and Project Builder.
>>
>> http://www.omnigroup.com/mailman/archive/macosx-dev/2000-May/001886.
>> html
>
> It's an example of NSArray, which we don't convert, so we live
> dangerously anyway in PyObjC as we don't even have the hint from the
> header that we _shouldn't_ mutate even if it is mutable.

I think you should read this as 'even though some methods are defined 
as returning an NSFoo they may return any subclass (like NSMutableFoo), 
depending on the actuall type is bad'. Read like that this is pretty 
relevant to our discussion: If we convert NSString and wrap 
NSMutableString (a subclass of NSString) the user may sometimes get a 
python string object and sometimes not from functions/methods that are 
documented as returning a NSString. Unless we can make sure that the 
NSMutableString wrapper is usable everywhere where a Python string is 
this will give us great headaches in the future.

Ronald