Proposal for nicer init() about rubicon-objc HOT 10 OPEN

@dimaqq The call would be:

UIWindow.alloc().initWithFrame(UIScreen.mainScreen.bounds)

The first argument is always a positional argument; all subsequent arguments are keywords.

from rubicon-objc.

Pythonista's objc_util module supports calling Objective-C methods using keyword arguments like this, and it definitely helps with readability. Sounds like a good idea to me.

This would also be a good use case for PEP 468's order-preserving keyword arguments, which are available as of Python 3.6. Ordered keyword arguments are not necessary for this feature though, they are just an optimization - on older Python versions, the correct method name would need to be guessed, by trying every possible permutation of the keyword arguments, until a valid method name is found.

from rubicon-objc.

Completely agreed that this sounds like a good idea - it's just a matter of implementation. Since argument order isn't guaranteed (until Python 3.6, anyway), that means the lookup process will be (a) O(2^n) complexity for the number of arguments, and (b) potentially ambiguous, because the method method(arga=1, argb=2) will match methodWithArga:Argb: and methodWithArgb:Arga:.

I'm not sure if the latter will be a problem in practice - and it becomes a non-issue under Python3.6 - but it's worth keeping in mind.

There's also a minor issue of how initWithArgA:ArgB maps to a method call; it would be nice if the method was init(argA=..., argB=...); but we might need to compromise with initWith(argA=..., argB=...) - unless of course, the "with" becomes a magic keyword in method names.

from rubicon-objc.

To keep it simple at first, maybe it would be good to require initWithArgA(..., argB=...). Then the only thing that needs to be done is inserting the :s after each selector part (after initWithArgA and argB). More advanced "name guessing" could be added later. It would also halve the "guessing time" on Pythons with unordered kwargs.

from rubicon-objc.

Quick update - I've played around with this a little and implemented a basic version of this feature (in my local copy of the repo). The current implementation is not very good though. Right now, when any nonexistant attribute is accessed on an ObjCInstance, it is always interpreted as a method call with kwargs, even if there is no method that starts with that name. This breaks a couple of tests that require nonexistant attributes to raise an AttributeError. I also think it's not a good solution to magically make every attribute exist.

As a (hopefully better) alternative I'll try caching all instance methods when an ObjCClass is created. This way, we know in advance which method names exist, and can create attributes for those specifically. I don't know how well this will perform, since the entire method list of the class and all superclasses needs to be looked through. At least it only needs to be done once per class, so if there is a noticeable performance impact, it will only be when each class is first loaded.

from rubicon-objc.

Okay, PR has been made. The way I implemented it now uses sets as dictionary keys to look up the method for a set of kwargs. This doesn't depend on PEP 468, so it should work equally well on all Python versions. I haven't tested the performance of the new syntax much, but the unit tests run in about the same time as before, so hopefully it shouldn't affect the speed of existing code much.

from rubicon-objc.

So, now that PR is merged, what's the new way to do the following?

UIWindow.alloc().initWithFrame_(UIScreen.mainScreen.bounds)

Or are we not there yet?

from rubicon-objc.

Oh, cool, I didn't realise that.

Would be nice to have that documented :)

Here's what I can do now (it works, I hope I understood why):

-            rv = view.dequeueReusableCellWithReuseIdentifier_forIndexPath_("knob", path)
+            rv = view.dequeueReusableCellWithReuseIdentifier("knob", forIndexPath=path)

from rubicon-objc.

Documentation is definitely needed (but that's true of most of Rubicon...) - but AFAICT, this has now been implemented. If I'm mistaken, please re-open this ticket.

from rubicon-objc.

Reopening this for now - there are two suggestions from the OP that are not yet supported:

• Leaving out the with parts of the init selector: DGFoo.alloc().init(foo="spam", bar="ham") translates to [[DGFoo alloc] initWithFoo:@"spam", bar:@"ham"]
• Leaving out the explicit .alloc().init(...) entirely: DGFoo(foo="spam", bar="ham") also translates to the above

IMHO both of these would be good to have as they would make object creation shorter and more readable. This is also basically what Swift does when it imports init methods from Objective-C.

from rubicon-objc.