Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa
Brought to you by:
ronaldoussoren
From: Bill B. <bb...@co...> - 2002-10-17 16:24:37
|
On Thursday, October 17, 2002, at 12:00 PM, pyt...@py... wrote: > I'll never 'win' this discussion, as if that is meaningful, but the > syntax serves another purpose. The main reason I like it is because I > don't like calling conventions that list parameter names and values in > separate places. Agreed on conventions -- I like ObjC's and SmallTalk's calling conventions much better for exactly the reason you describe. Minor correction: There are no named parameters in Objective-C. The method "setObject:forKey:" is named "setObject:forKey:" -- not "setObject: that takes an argument called forKey:". > With the underscore convention, you have essentially > (pseudocode): > > call((a,b,c), (1,2,3)) > > when the *meaning* is > > call(a=1, b=2, c=3). The underscore convention turns... [aDict setObject: foo forKey: @"bar"] ... into ... aDict.setObject_forKey_(foo, "bar") That's it. Given that there aren't named parameters, I'm not sure what the above statement is intending to mean. > But I'm definitely not the target audience for pyobjc, so I would > ignore > all of my comments at this point. I love Python and I love > Objective-C. I see no reason to write GUI Cocoa code in Python when > Objective-C does it perfectly and the GUI api was meant for use with > Objective-C. Four big reasons to use Python: - rapid development: With Python in the mix, I can reduce the compile-run part of the edit-compile-run to almost non-existent (as soon as I get class reloading working -- haven't had time to go there). In my experience, it has *vastly* improved my productivity. - access to tools: The Python world has an awesome-- both quantity and range-- variety of tools and libraries available that may not be available directly in ObjC. By using PyObjC, I can write my UI widgets in ObjC, glue 'em together using a mix of Python and ObjC, and leverage whatever tools I need from the Python world. - efficiency of implementation: There are certain tasks that Python is incredibly well suited for; writing command line tools (getopt, modularity, etc...) and implementing/using network protocols, to name two examples. Concrete example: By switching from the WebServices API provided by Apple to the xmlrpclib provided in Python, I was able to reduce the number of lines of code in the network client portion of my Cocoa app by roughly 70% (well over several hundred lines of code). At the same time, I gain.... - portability: While the Cocoa specific bits of my app are not portable, my entire communication layer is. Since my app is a client on top of a remote server and I also needed to create a command line client for the purposes of testing and automation.... and I needed to support many platforms on everything but the GUI specific bits, I chose to implement my client library in Python. It is 100% portable-- runs everywhere-- including in my ObjC/Cocoa OS X specific GUI application.l Not only did I eliminate 70% of the client side ObjC code in my Cocoa app, but I also reduced my code duplication -- I only have to write *one* client package. > I thus think it would be far more useful to have a simple way to link > an > Objective-C nib-based GUI controlled by a Python backend, with > convenience wrappers to convert complex library types like dictionaries > and mutable arrays. I believe most of this is already done. I certainly have a complex ObjC app using a python backend/client-library to talk to the server and control the UI -- it is up and running now and works very well! Convenience wrappers are in the works. Instead of wrapping, we are thinking of simply providing a subclass of NSDictionary and NSArray that can encapsulate DictType and Array/TupleTypes respectively. That way, Python arrays and dicts will behave like normal NSArray / NSDictionary instances on the ObjC side of the bridge. (The other direction has already been bridged). b.bum |