Re: [Pyobjc-dev] NSString & mutability

[Mike F. <mi...@lo...>]

I am not entirely clear about what exactly is being discussed here... 
this message was forwarded to me by Bill.

I will make the point (which Bill already undoubtedly knows) that in 
Cocoa the types declared for arguments and return values in the API are 
more about what the caller can do with the return value or what the 
method will do with the argument rather than what the return value 
really will be or what the argument must be.

For example, NSView's -subviews method is declared to return an 
NSArray.  Forever it has actually returned an NSMutableArray: the one 
it uses to manage its subviews.  The fact that it declares the return 
value is NSArray means that the caller is not allowed to change it, not 
that it CANNOT be changed.  In reverse, NSWindow's -setTitle: takes an 
NSString.  That does not mean I cannot pass it an NSMutableString, it 
means that under no circumstances will the window alter the string, 
even if it is mutable.

Mike


Begin forwarded message:

> From: bb...@ma...
> Date: Tue Feb 4, 2003  1:37:00 PM US/Pacific
> To: pyo...@li..., mf...@lo...
> Subject: Re: [Pyobjc-dev] NSString & mutability
>
> On Tuesday, Feb 4, 2003, at 15:56 US/Eastern, Just van Rossum wrote:
>> 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.
>
> I'm not willing to accept a surprise like that because it will greatly 
> reduce the value of PyObjC in quite a number of situations.   This is 
> not idle speculation.   I have made the same mistake in the past 
> [creating a bridge that was dependent on internal implementation of 
> underlying frameworks] and it rendered the bridge [Tcl <-> ObjC, in 
> this case] nearly useless until it was fixed -- it broke-- or 
> sometimes didn't break-- depending on what order the user did things 
> simply because some random bit of code somewhere chose to return 
> *this* private subclass vs. *that* private subclass as some internal 
> optimization hack that was *not* apparent, no relevant to, the 
> advertised API.
>
> The fundamental problem is that partial conversion relies on the 
> internal implementation to stay the same over time.   The current 
> behavior does not;  it remains consistent.  Partial conversion 
> behavior that is dependent upon the internal implementation of 'third 
> party' [Apple is a third party, in this case] frameworks will lead to 
> behavior that changes over time and through factors outside of our 
> control.
>
> More below....
>
>> Can you please give an example of an _actual_ problem? I'll have a go
>> myself:
>
> Off the top of my head, no-- I can't remember a specific example.  But 
> that is mostly because I have been relying on the APIs as advertised 
> by the classes and not their internal implementations for long enough 
> that I haven't had this problem in a while.   It *does* come up on the 
> mailing lists on occasion, but searching for "nsmutablestring nsstring 
> return" yields an awful lot of noise hits.
>
>> 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.
>
> I agree that the situations where this arise will be rare.   But, when 
> they do arise, the results are the absolute worst kinds of bugs in the 
> world to fix.  It breaks on customer A's computer, but not customer 
> B's -- but they are [supposedly] identical.  Oh, wait a minute, 
> Customer B upgraded to version 1.234b of the some random plugin while 
> customer A is still using 1.233.
>
> Another exmaple: What if Mike [who I included in this because he may 
> have some useful input-- sorry, Mike :-] changes the implementation of 
> TextExtras and throws an NSMutableString into some random object 
> collection that ends up on the other side of the bridge at some point? 
>   The Python developer is screwed if there code breaks.
>
> What happens when Apple ships the 10.2.5 update and they change some 
> random bit of internal implementation such that a method that used to 
> return (NSMutableString*) now *always* returns (NSString*)?   Assuming 
> the PyObjC developer can figure out what is going on, are they now 
> supposed to write OS X version specific code at the x.x.1 level?
>
> Now-- what about the developers that will be using PyObjC with 
> multiple thousands of lines of code embedded in random frameworks 
> across some large scale system?   For them, the choice of using PyObjC 
> now comes with the cost of having to ensure that every method that 
> *may* return an NSMutableString* when it is declared with an NSString* 
> return value is identified and compensated for.   This is not a 
> contrived example-- I and a number of people I have been in contact 
> with since PyObjC became a visible project again-- have used PyObjC in 
> this context in the past and are planning on doing so in the future 
> [some already are].   This would be a deal killer for them.
>
> Bottom line:  PyObjC -- just like the AppleScript in an AS Studio 
> project or a good chunk of the ObjC in a pure ObjC Cocoa app -- is the 
> glue that holds together all of the random objects in a fashion that 
> solves whatever problem the developer is trying to address.   The 
> developer does not have full and complete control over those objects-- 
> heck, there may be entire chunks of implementation present that their 
> code has no awareness of whatsoever [TextExtras].    For such a system 
> to work, the objects must be glued together as advertised by the APIs. 
>   To do otherwise will render a system that is fragile.  Worse, it 
> will create a system whose fragility is dependent upon unreasonable 
> expectations.
>
> It is reasonable to expect-- and history indicates it is true-- that 
> the behavior of the NSCell API will remain consistent going forward.  
> It is unreasonable to expect that the internal implementation will 
> remain consistent over time, yet that is exactly what a partial 
> conversion solution expects.
>
> b.bum
>