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

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

On Monday, Feb 3, 2003, at 20:12 Europe/Amsterdam, Just van Rossum 
wrote:
>
> 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.

The declared return and argument types aren't available beyond "it's an 
object". Most of these type declarations are only used for compile-time 
checks.
>> --
>>
>> 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.

The assumption could lead to bugs for some types (like integers): There 
is no guarantee whatsever on the value of 'id(x+1) == id(x+1)' if x is 
an integer. That means that you might think you add two different 
objects to a list while you add only one (or v.v.!)

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

Not necessarily, I'm sure we can come up with sane scenarios where 
object identity is used other than as a performance hack. That said: 
type *does* matter (see above).
>
> 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_).
And likewise for Python->ObjC: A new object will be created.

Ronald