Re: [Pyobjc-dev] Objective-P?
Brought to you by:
ronaldoussoren
From: Ronald O. <ron...@ma...> - 2009-11-12 10:33:19
|
On 12 Nov, 2009, at 11:18, Orestis Markou wrote: > > On 12 Nov 2009, at 11:59, Ronald Oussoren wrote: > >> What really annoys me though is that I haven't been able to find a way to get clear integration of Cocoa and Python without changing the Python syntax, and without using manual translation of method names (as was used by the Java-Cocoa bridge). > > I've given some thought to that in the past, and of course I know it comes up on the list every couple of months. It sure does, and to Anders credit he did come up with the first original idea in a couple of years ;-) > > I think an important step is maintaing the order of the **kwargs dictionary: > > def set(self, **kwargs): > # construct method name from kwargs > # extract positional args from kwargs > objc.dispatch(methodname, args) > > > foo.set(Value=1, forKey='a') > foo.set(forKey='a', Value=1) > > If those calls could be differentiated in the body of 'set', would it not help? Some cases could be ambiguous, but in that case a warning could be emitted and the current convention could be used instead. That would help a lot, assuming that the elements in selectors are unique. It would break down for a method like 'strokeFromPoint:toPoint:toPoint:' (which doesn't actually exist). That method would need two 'toPoint' keyword arguments, which is not possible at all. It should be possible to compile a mapping from the list of keyword arguments to ObjC selectors when a class proxy is initialized, but I'd like to avoid that. I'm not to happy about the current work we're doing when a class proxy is fully initialized (when it is first used), and am thinking about ways to reduce that work not add more. Dynamicly probing should of course also be possible (that is, try 'forKey:setValue' then 'setValue:forKey:' and cache which one works). Ronald |