Re: [Pyobjc-dev] NGPython

[Helge H. <hel...@op...>]

On 01.03.2004, at 18:08, b.bum wrote:
> Please read the rather long thread on python-dev.  All of the points 
> you raise have been addressed in that thread.

Well, I think I have very well understood your point on that.

The reason why I still like the approach is that we have the experience 
that it works just great in practice, has little to no maintenance 
issues and is much easier to understand for non-Objective-C people. So 
you may or may not follow on that, your decision ;-)
Really no point in discussing that.

> This is a subject that has come up every 18 months to two years for 
> the history of the PyObjC project (since 1994/1995) and the change has 
> not been made yet.

Well, at least I can provide code for getting started, I guess that 
validates bringing up the topic yet another time ;-)

> A mapping based solution attemps to "port" the Objective-C API into 
> Python in a "Pythonic" fashion.  The end result is an API that is 
> neither Objective-C nor Python.   It sort of looks like Python, but 
> there will be all kinds of weird little special cases resulting from 
> the underlying C nature of Objective-C.

Actually this is less a problem with Python since you can override all 
the Pythonic stuff (for iterators, attributes access etc) and make 
Objective-C objects look like regular Python ones.

> A mapped solution ensures that the developer cannot look in either of 
> these places to find canonical information as to what they should 
> implement.

Only if the mapping is unnatural and difficult to understand. Which it 
isn't.

Besides that its not a big deal at all to write a small Python script 
which generates new index files into Objective-C documentation which 
takes mappings into account.

> Furthermore, the Objective-C method names are meaningful.   
> -setObject:forKey: says more than just "this is a method named 
> 'setObject:forKey:', it also gives information about the arguments and 
> their order (and, no, they are not named arguments).   A mapping based 
> solution loses all of that.

I don't see why. You can of course map the selector setObject:forKey: 
to a method named setObjectForKey in case you want to do that. After 
all thats the whole point - making better user-level method names which 
are natural in the host language.

Note: the pybridget tool also supports matching based on positional 
parameters, not only on keywords.

> This was one of the primary complaints about bridged Java (and WO 
> 5.x).   The Java APIs were a mutated Foundation.   It was less 
> approachable to new developers because the API was not as 
> self-descriptive.

If you say so. I think its more a problem of having various different 
collection classes and few ways to mix their usage (say List vs NSArray 
vs Collection.Array vs JGL vs ...).
But, no point (and interest ;-) in discussing that.

This isn't so much a problem with Python where Foundation collections 
can act like regular Python collections.

>> Anyway, we can let the thread stop here, my posting wasn't really 
>> meant to start a flamewar but to offer some code in case someone is 
>> interested ;-)
>
> No flamewar -- I don't think you understand how much thought, effort, 
> and engineering has gone into the current implementation, including a 
> lot of thinking as to how to make a mapping based solution work.

OK. I can ackknowledge that, in case you also understand how much 
thought, effort, and engineering were done in the NGPython 
implementation, including a lot of thinking as to how to make a mapping 
based solution work ;-)

I did not want to start a discussion, if PyObjC people have decided not 
to do any mapping, its their choice, no discussion about that. I *only* 
offered some code which could help getting started with that and 
mentioned, that the approach worked just fine for us.

>> BTW: your post fails to list the really interesting parts, like the 
>> required reverse mapping of selectors for subclassing Objective-C 
>> objects in Python.
> Subclassing works fine.

Yes, of course, but its more interesting (difficult) with a mapping 
framework in place ;-)

> Go read the python-dev thread, there is a lot more info there....

Sorry, not enough sparetime.

best regards,
   Helge
-- 
http://docs.opengroupware.org/Members/helge
OpenGroupware.org