[Pythonmac-SIG] pyobjc / cocoa

[Ronald Oussoren]

On Wednesday, Oct 16, 2002, at 15:17 Europe/Amsterdam, Jack Jansen 
wrote:
>
> I think that what I would like is one static scheme that is the same 
> (or almost the same) as the Java/ObjC naming scheme, plus a fallback 
> scheme (which could be the current message_withFoo_ scheme). There may 
> be a problem here with overloading, though: if I look at AppKitJava 
> there's often multiple ObjC selectors that map to one Java method 
> name, I'm not sure how they handle this, especially in the face of 
> overriding ObjC methods from Java.

I agree that using the naming scheme as from the Java-Cocoa bridge 
would be usefull. Making up yet another naming scheme would be IMHO be 
unwise, if only because this would make it very hard to find 
documentation.

W.R.T. mapping multiple selectors onto the same java method in the Java 
bridge: I suppose these are selectors that are logically 1 method with 
a number of default arguments, and the ones with less arguments 
probably call the ones with more arguments:
	[object foo]	-> [object fooWithArg:nil andNum:nil]
	[object fooWithArg:arg] -> [object fooWithArg:arg andNum:nil]
	[object fooWithArg:arg andNum:arg2]

>
> The static scheme could simply be a Python dictionary (or an 
> NSDictionary, but a Python dictionary is easier to initialize, I 
> guess) that we initialize with Python code, where the Python code is 
> generated by running /Developer/Java/Jobs/*.jobs through a script. 
> Fastest is probably to create both Python->ObjC and ObjC->Python 
> dictionaries.

I was thinking along the same lines. The actual datastructure should be 
hidden,
you'd just call a global function in the objc module to map an 
Objective-C selector on a Python method name.

>
> Is it still possible to have two name mapping schemes, where first one 
> is tried and then the other? Or would this wreak havoc now that we 
> have two-way inheritance and such?

Having two mapping scheme's is not really a problem. That is, unless 
you want to be able to access a method using both mapping schemes at 
the same time.

The current code does something like the code below while creating a 
proxy class for and objective-C class:

def map_selector(sel):
	return sel.replace(':', '_')

def make_methods(ocClass, clsDict):
	for meth in ocClass.methods():
		clsDict[map_selector(meth.selector)] = wrapMethod(meth)

The proxy class is created once including all methods. There is some 
additional code that recalculates the class dict whenever the method 
list of the Objective-C class changes. This may happen when loading a 
bundle that defines additional categories for existing classes.

It would be fairly easy to replace the 'map_selector' function by a 
function that first does a lookup in a translation table.

IMHO it is highly unlikely that users define completely new selectors 
in Python, other than new actions for use in Interface Builder, and I 
already have written a module that reads the classes.nib from a .NIB 
'file' and creates a python module containing the corresponding python 
classes. Using names without underscores for IBActions is therefore 
very easy.

Ronald