[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bill Bumgarner]

On Thursday, October 17, 2002, at 12:00 PM, 
pythonmac-sig-request@python.org 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