Re: [Pyobjc-dev] Passing Python objects to ObjC again.

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

bb...@ma... wrote:

> I may be missing something here, but this sounds like normal
> behavior.
> 
> Specifically:  If you pass a pure Python object reference into
> Objective-C, it will behave like an autoreleased object.  That is, if
> you want to hang on to the object on the ObjC side, you need to
> -retain it just like you would any other object.

But the thing is, you don't have control over the autoreleased proxy
that get created for your Python object. That makes passing
(non-NSObject inherited) Python objects to ObjC more dangerous than
passing (NSObject inherited) objects. I don't care _too_ much about this
additional danger, but it would help newbies if it was clearly
documented somewhere.

> One can assume an object reference is only valid in the current scope
> unless the reference is -retained.  In ObjC, the -retain must be
> explicit.  In Python, an assignment or set membership implies the
> -retain (which can be confusing to the ObjC programmer if they expect
> an object to behave as autoreleased but it -releases at end of
> current scope).

But it's confusing to Python programmers (or at least: it was to me ;-)
that even though you explicitly keep a ref to the object, the proxy that
gets passed to ObjC is autoreleased, which may lead to crashes if the
receiver doesn't retain it, yet uses it after the current
autoreleasepool is deallocated. Completely understandable once you
understand how it works (it was quite a "duh" experience for me ;-).

> At least, that is how it should work.
> 
> In the case of NSNotificationCenter, the notification center
> maintains weak references-- non retained references-- to the various
> observers. I have always felt that this was an unfortunate
> implementation decision as it has led to a tremendous number of very
> confused programmers.

After having implemented a similar scheme in Python (and having looked
at how the anygui guys were doing the same thing), I totally understand
why it doesn't keep real refs: if you do keep real refs, you're in
cyclic ref hell before you know it. In Python you could use the weakref
module, but even that is tricky: the most natural way to register
observers is to add a bound method (semantically similar to a
target/selector duo), yet bound methods are made on the fly, so the
bound method _itself_ is not referenced by anyone else, so will go away
if you only keep a weak ref to it. You really need a weak ref to the
target itself. I think it's far less of a problem now that Python has a
cycle detector.

> The goal was that an object's role as an
> observer should not affect the retain count and that the developer
> should invoke -removeObjserver: in -dealloc.  The reality is that the
> developer should decouple the "I'm not going to use this object
> anymore" code from the reference counting code-- yields much cleaner
> code that uses resources more efficiently.

Heh, but this _utterly_ defeats the purpose of ref counting...

Just