Re: [Pyobjc-dev] Need design input for method names
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2009-03-30 13:45:28
|
On 29 Mar, 2009, at 18:42, Orestis Markou wrote: > It occurs to me (having started to do Obj-C development this past > month full-time) that a major source of annoyance is not the > verboseness of the bridge, but the lack of a Pythonic API to Cocoa, > which can be very verbose itself. > > One approach taken from the Ruby guys is HotCocoa (http://www.macruby.org/trac/wiki/HotCocoa > ) that aims to provide simplified wrappers for common Cocoa use- > cases. For example, rather than doing: > > win = NSWindow.alloc.initWithContentRect [10,20,300,300], :styleMask > => ( > NSTitledWindowMask | NSClosableWindowMask | > NSMiniaturizableWindowMask | NSResizableWindowMask) > you do: > win = window :frame => [10,20,300,300] > However, I know that the PyObjC maintainers don't want to do this > since it has to be manually maintained. Perhaps then this can be > another project? Maybe the fact that as bbum said there hasn't been > an acceptable solution for 15 years now is in an indicator of wrong > scope. Even if an acceptable method name convention can be reached, > the fact that to create a usual NSWindow you need to pass in 4 flags > won't go away. The reason I don't like HotCocoa's approach is that someone will have to write and maintain that layer, including good documentation. The past has learned that "someone" tends to be me in the long run, which makes me very hesitant to work on this. The advantage of the current approach is that we can point users to Apple's documentation because translating from ObjC to Python (and v.v. is trivial). That said, I'm very slowly adding some shortcuts to PyObjC where that makes sense (such as a number of contextmanagers in the CoreGraphics bindings), and will add more in the future. One of the items on my todolist is to check if we can adopt Twisted-style deferred's and their generator-based pseudothreads to make dealing with sheets easier. To summarize: I'm not totally against a HotCocoa-style add-on for PyObjC and am willing to ship is as part of PyObjC itself. This would need commitment from a number of people to get going though, and I'd very much prefer if the Pythonic addons were as complete as possible before merging them into the core framework wrappers to avoid getting stuck with partial addons that noone is willing to maintain or enhance. BTW. "as complete as possible" means covers all API's that are part of Cocoa and other useful frameworks in SnowLeopard. What's needed most is a PEP-style document that describes what the goals of this work would be, including descriptions of the way to map Cocoa API's onto Python API's in a consistent manner. This document will also have to describe how to deal with subclassing. Don't worry about getting it 100% correct on the first try. Ronald > Orestis > -- > or...@or... > http://orestis.gr/ > > > > > On 29 Mar 2009, at 19:21, Ronald Oussoren wrote: > >> >> On 29 Mar, 2009, at 13:11, Bill Bumgarner wrote: >>>> >>> >>> This again? :) >>> >>> Here is a good starting point for one of the more signal-oriented >>> discussions on this subject (it has come up once every 6 to 24 >>> months >>> since PyObjC was created in '94): >> >> I know, but the current syntax really annoys me. >> >> Ronald >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Pyobjc-dev mailing list >> Pyo...@li... >> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev > |