[Pyobjc-dev] Re: memory management

[<bb...@ma...>]

First, 	I would like to say THANK YOU!!!! to Jonathan LaCour for 
jumping into the discussion.  The input is very definitely appreciated.

First, what we are really talking about is a relatively small part of 
the overall problem.  That the bridge already automatically increases 
and decreases the retain count as python references to the ObjC objects 
are created and destroyed solves most of the problem.

The remaining problem is how to deal with the situations that require 
special casing on a per method basis.

On Monday, October 28, 2002, at 12:35 AM, Jonathan LaCour wrote:
> I have been watching the discussion on retain/release/autorelease 
> semantics for a few days and I have put some thought into things.  
> After a lot of thought, I would like to sincerely urge you to make an 
> attempt at abstracting out any and all retain/release/autorelease 
> responsibilities for the programmer.  I understand the argument that 
> it isn't very "Cocoa-like", but I feel that I have a compelling 
> argument here.

I think all of us agree wholeheartedly that eliminating as much of the 
retain/release/autorelease noise from the Python side of the bridge as 
is possible is a high priority goal.

> First, I believe that you alienate most python programmers by 
> enforcing memory management on them.  Python programmers use python 
> *because* they don't have to worry about this kind of thing.  Its not 
> that they don't know how or are afraid of it, they just don't want to 
> touch it.  If you force people into it, they will likely end up using 
> wxPython or something like REALBasic.

Agreed.  Keep in mind that we are not writing the Foundation, AppKit 
and the rest of the ObjC APIs in Python -- we are bridging them.   
While a bridge makes the functionality available on the other side of 
the bridge, there is always going to be evidence that the functionality 
on the other side of the bridge is implemented in a different 
technology.

> Secondly, to counter the "Cocoa-like" argument, placing memory 
> management functionality into a python product is simply not 
> "Python-like".  Sure, it will feel more like developing with Cocoa and 
> Objective-C, but people are going to use the Python bridge because 
> they don't want to work with Objective-C when they don't have to.  You 
> have to make a choice here... if PyObjC is for Cocoa developers who 
> don't know python, then certainly you should try and be "Cocoa-like."  
> But if PyObjC is for *python programmers* (which I have a feeling it 
> is), then it should strive to be Python like... meaning no 
> retain/release at all!

Reality:  If a developer is using the Objective-C bridge to write an 
application, they are developing in a combination of Python and 
Objective-C -- ObjC is still very much a part of the equation.  The 
developer is going to have to know *some* objective-c to get the job 
done.

The current bridge already changes the memory management semantics 
significantly -- it already obviates the need for calls to 
-retain/-release/-autorelease when making assignments (foo = bar), when 
dealing with set membership (-retaining an object before removing it 
from a set, if that object is to be returned), and when returning 
objects from methods.  These are the most common situations for use of 
the memory management methods in ObjC.

> Memory management through old-style reference counting stands directly 
> opposite to this power.  If you lose this, why use Python at all?  You 
> might as well just use Objective-C (it only takes a few minutes to 
> learn) and is faster than python.

Because python provides much better rapid turnaround than Obj-C ever 
could.... my compilation time drops to near nothing and I can eliminate 
100s of lines of code that would be required in ObjC to do the same 
thing.   That, and I can take advantage of the incredible array of 
python modules that are available.   Example:  I can now use the 
berkeley db as a persistent store from my Obj-C apps with only a 
handful of lines of code.

> When this project came along I was extremely excited about the 
> possibilities that it offered.  Please consider at least making an 
> automated system an OPTION.  I know its hard, but I think that in the 
> long run it will be worth it.  A system like Cocoa without manual 
> memory management using a language like Python and Mac OS X's 
> developer tools is such a powerful concept and could truly be the 
> "killer app" of development on Mac OS X.

It can't be an option -- if it is used in one hunk of code and not in 
another, those two hunks are incompatible.   I.e. if I create a 
framework that contains Python that doesn't use the option and your app 
uses the option, you can't use my framework.

Even without the option, the bridge as it stands today provides the 
features that you speak... more on that in the next message.

b.bum


b.bum
Are you laughing?
	... they are.