[Pyobjc-dev] Re: memory management
Brought to you by:
ronaldoussoren
From: <bb...@ma...> - 2002-10-28 15:42:16
|
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. |