Re: [Pyobjc-dev] Auto bridging instances by conversion

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> Unfortunately, it is not that simple; not that black/white.

Is it ever? ;-)

> It is quite possible-- used to be common, but I'm seeing it less and 
> less often-- for a method that is declared as....
> 
> - (NSString *) fooBar;
> 
> .... to actually return an instance of NSMutableString.   Contrary to 
> initial belief, this is not a bug.   NSString is a superclass of 
> NSMutableString-- the declared return type tells the developer that 
> they should treat the string as immutable and the developer must do so 
> unless they either either want to put up with a bunch of compiler 
> warnings or do an evil downcast for an object not their own.

I recently learned about this but hadn't thought of it in this context.
I don't assume the _declared_ return type is available at runtime? If
so, we could use that, but I guess it isn't.

> As such, we really can't limit conversion of strings to just the 
> immutable strings while leaving the mutable strings alone.  The end 
> result would be vast amounts more confusion than we currently have -- 

Where the value of "vast" depends on how frequently this pattern
actually occurs in the call you use.

> there are situations where a method may return an NSString* instance 
> some of the time and NSMutableString* instances at other times.
> 
> However, I believe that *not* converting NSString and using a bridging 
> mechanism similar as to what is used for NSArray and NSDictionary may 
> work quite well.

Hm, perhaps you're right.

> --
> 
> Python -> ObjC
> 
> This is easy.   Simply create a subclass of NSString that
> encapsulates an instance of a Python string [or character buffer] and
> implements the appropriate primitive methods.   From there, it should
> "just work". No need to also provide a subclass of NSMutableString
> because Python strings are always immutable -- correct?

Correct.

> --
> 
> ObjC -> Python
> 
> A more difficult case because there isn't [yet] a <string> base type
> to inherit from that is used for all 'are you a string' testing.
> 
> However, if one were to implement a Python module that providing a 
> <character buffer> type API that wraps around an NSString [immutable 
> only] instance, it appears that most of the Python core would handle 
> that particular argument just fine.
> 
> Example:   the open() or file() functions would work just fine as
> long as the inbound object for the <name> argument is a character
> buffer (as that function-- open is just an alias for file anyway--
> uses 'et' as the parse format for PyArgs_ParseTupleAndKeywords()).

But what about (say) regular expressions on unicode strings?

> --
> 
> Furthermore, the (id) of an object-- the address contained in self--
> is often used as a meaningful identifier.   If a developer places an
> object into a container-- a dictionary or an array-- they expect to
> retrieve the exact same instance-- the same self pointer-- upon
> retrieving that object.

Such an assumption is only safe if the code works directly with these
collection objects. I don't think any code can be called sane it it
stops working when it receives an object from elsewhere that has a
different id than it expects.

> In this context, that an object is an (int) and the first 100 ints are 
> singletons is completely irrelevant.   Consider the object in pure OO 
> terms-- it is just an object contained in a collection, its type does 
> not matter.

I don't see why the id should matter either. From a Python perspective,
all that matters is that the two objects compare and hash equally. Sure,
comparison is _cheaper_ when the two objects have the same id, but would
stuff actually _break_ if the id's weren't the same? That's just sick.

> In my experience with bridging-- many years and going between a
> number of different languages--

(Do you have a macro for that sentence? ;-)

> conversion always turns out to be a
> headache. Sometimes, there is more benefit from doing the conversion
> than there would be from not doing so,  but that is *rarely* the case
> and there is *always* a price to be paid for doing the conversion.
> 
> Do not discount the performance hit -- it can be truly nasty.  

Yet Python is _primarily_ about convenience. Efficiency is secondary.
Using Python comes at a price, and every bridge causes some overhead.
For example passing a C string to Python *always* causes the string to
be copied. I don't see what's so inherently bad at treating NSStrings
the same way.

Regarding numbers: from ObjC -> Python there will be hardly a difference
between conversion and wrapping: for both cases a new object needs to be
allocated (except when the number is between -1 and 99 in which case
conversion is _cheaper_).

It's _great_ that wrapped NSArrays work much like lists but aren't, and
I wouldn't want it any other way, but a number should really be a
number.

> In the context of the Java<->ObjC bridge, the fact that
> Strings<->NSStrings conversions occur means that bridged code using
> ObjC collections is so astoundingly slow and memory inefficient as to
> require the developer to often change the design patterns radically
> (at least, that *was* the case with the WO 4.5 / OS X PB and prior
> bridge -- don't know if it still is, but I imagine it likely is).  

I don't buy this: why use Foundation collections on a large scale in a
_Python_ app? The situation where *both* Python and ObjC need to access
a dict in tight loops sounds fairly unlikely. You can choose
NSDictionary or dict depending on whether Python or ObjC will need to
access it most frequently.

Just