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

bbum@mac.com bbum@mac.com
Wed, 16 Oct 2002 18:48:22 -0400


On Wednesday, October 16, 2002, at 06:32 PM, Jack Jansen wrote:
> On woensdag, oktober 16, 2002, at 05:34 , bbum@mac.com wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Let me clarify:  I don't necessarily think it is A Good Thing.  I'm 
just convinced that it is better than solutions that involve presenting 
a significantly mangled API on the other side of the bridge.

The current _ based mapping system falls clearly under the KISS 
principal -- it is simple, slightly ugly, and just works.

>
> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And I've heard of more people with this reaction. 
> So, if we care about winning existing Python programmers over to Cocoa 
> (which I think we should: even though Carbon is going to be around for 
> a long time it'll only be interesting to existing Mac programmers, and 
> Cocoa has the potential to win over unix and windows Python people) we 
> should make sure it looks appealing.

I completely agree (including the UGLY!! part).   A part of making it 
appealing is making it easier to work with or more powerful than 
working with the existing compiled ObjC based tools.

The current model-- though ugly from a traditional python viewpoint-- 
is easy to work with in that it is very easy to map between 
Python<->ObjC and it is extremely powerful-- more powerful than 
straight ObjC-- in terms of both rapid turnaround time and ability to 
leverage the vast wealth of Python tools/frameworks/libraries that are 
available.

> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

(I would also like to see effort invested in making the ObjC classes 
behave like proper Python classes where possible and vice-versa.  For 
example, would it be possible to pass things of type PyDict across the 
bridge from Python->ObjC such that they behave like a subclass of 
NSMutableDictionary?  I think so, but am not sure.)

As much as I have been extremely vocal in my opinions on this subject, 
I'm also a very reasonable solution.  As long as the underlying system 
remains as transparent and workable-- though UGLY!!-- as it currently 
is, I'm all for changes that will attract a larger audience.

At the same time, I don't want to see the [somewhat limited] developer 
resources devoted to fixing problems that don't exist or to providing 
solutions that, in the end, no one will use.

The Java bridge almost falls into the latter category -- almost in that 
there are a handful of developers that have either stuck with it or 
need to use it to access Java only functionality.

If you look at the cocoa-dev mailing list archive, there is a boatload 
of posts from people that started with the Java/Cocoa APIs, worked with 
it for a while, and either gave up or picked up ObjC.  Of those that 
picked up ObjC, they have become some of the most vocal proponents of 
the language!

There are really two problems here:  One of marketing, one of a 
technical nature.

On the marketing side, if providing a layer on top of the existing 
PyObjC system will make it more palatable to a larger degree of Python 
programmers, there is certainly value within doing so!

I do feel strongly that most programmers that come through this route 
will eventually find themselves using the '_' notation more and more 
often for three key reason;  it immediately indicates where the bridge 
is crossed (which, regardless of the transparency of the bridge, that 
the bridge has been crossed is important), reduces maintenance costs 
over time, and provides the maximum interoperability between Python and 
ObjC with the least amount of effort.

On the technical side... well, you know my feelings on the technical 
side -- that has been what the thread has focused on!

b.bum