Re: [Pyobjc-dev] NGPython

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

On 01.03.2004, at 07:26, b.bum wrote:
>> I think that this was much more beautiful than the current automatic 
>> ":" => "_" scheme used in PyObjC ;-)
>
> It fails this simple test:  can the mapping rule be expressed as a 
> single rule.
> The ":" -> "_" mapping, though ugly (really -- none of us are attached 
> to it), can:
> "Given an ObjC method name, replace all ":" with "_" to find the 
> python name."
> A 'bridget' style mapping cannot.

Could you elaborate? What do you mean by "can be expressed as a single 
rule"?  Do you care about speed?
Of course the mapping "can" be expressed as a single rule as long as it 
is unique.

> There will be special cases and the end result will be a new language 
> that is effectively a hybrid between Python and Objective-C.

Absolutely not, this is just regular Python - a function which does 
different things depending on the input parameters. Of course the 
developer need to know about the used libraries in any case.

> Just like the Java<->Objective-C bridge, such an approach to "mapping" 
> Objective-C methods into Python in a "Pythonic" fashion will yield 
> something that requires the developer to learn a new language.

I can't see why. Indeed he does need to know much less about 
Objective-C than before if he doesn't do exotic things.

> To use the provided examples:
>>   set = NSSet(array=myarray)
>>   set = NSSet(set=otherSet)
>
> Neither of these are meaningful to either the Python or Objective-C 
> developer.

Well, all Python developers I know can perfectly deal with that. Its 
just regular style, eg extensively used in Zope.

> The current form is as follows:
>
> set = NSSet.setWithArray_(myarray)
> set = NSSet.setWithSet_(otherSet)
>
> While the trailing '_' are unpalatable to the traditional Python 
> programmer, it is extremely clear exactly what the code is doing.  If 
> not, the developer only has to remember one rule to figure out what 
> bit of Foundation documentation to read to figure it out.

There are obviously situations where and explicit factory makes a lot 
more sense, yet, in the case of NSSet its awkward and unintuitive for 
Python developers (and even Objective-C developers will get into 
difficulties to know what syntax to use in what situation).

> Relevant post here:
> http://www.pycs.net/bbum/2003/11/29.html

OK, your position understood ;-) We had none of your issues listed 
(neither speed nor maintenance) and used the stuff in real world 
applications for some two years or so. Writing .jobs files is a 
no-brainer and there is nothing which prevents you from falling back to 
"ugly" syntax in case there is no mapping.

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 ;-)

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

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