Is inheritance working fully on the Python side? about rubicon-objc HOT 8 CLOSED

The class declaration itself is working fine, the issue here is with our current implementation of send_super. The issue is actually very similar to a problem that can happen when using Python's super incorrectly, as in this SO question. Our send_super does the Objective-C equivalent of super(self.__class__, self).method(), which causes infinite recursion for the reason explained on SO. The fix is also the same - we need to change send_super to accept a class above which to start searching for the method, instead of always starting at self's superclass.

from rubicon-objc.

Ah well I'm super happy the python side sets up the objects correctly then! That's actually incredibly valuable to me to know.

So this is a generic python problem, huh? I did not know that. This reveals my relative newness to python, still.

So in our case would: super().init() work if you know that super is a python-side class? Or does our __getattr__ implementation interfere with python's proxy 'super' instance that is returned?

EDIT: yeah, no that doesn't work because the instance is actually ObjCInstance, duh. Oh well. I give up. :)

from rubicon-objc.

Sorry, my answer may have been a bit short. Python's super isn't involved here at all. However, the issue with our send_super is similar to a problem that can happen with Python's super, that's why I mentioned it. I'll try to explain a bit.

When you call an Objective-C method normally ([self method]), the runtime looks for an implementation of the method in self's class. If there is none, it looks in the superclass of self's class, then in the superclass of that, etc.

When you call a superclass method ([super method]), the behavior is a bit different, because the call ignores the method's implementation in the current class (and any subclasses). To do this, the runtime starts searching for implementations in the superclass of the current class, rather than starting at self's class.

In the case of super, it's important that the starting class is remembered when the method is defined. The current send_super implementation doesn't do this correctly - instead, it determines the starting class dynamically based on self's class, which means that the starting class changes depending on self's runtime class. This is what causes the infinite recursion. Here's what happens when you call MyB.alloc().init() with our buggy implementation of send_super:

• self is an object of class MyB.
• When self.init() is called, the runtime searches for an init method in self.objc_class, i. e. MyB. That method exists, so it is called.
• MyB.init calls send_super(self, "init"). Rubicon asks the runtime to call self.init() and start method lookup in self.objc_class.superclass, i. e. MyA. That method exists, so it is called.
• MyA.init calls send_super(self, "init") again. The same thing happens as before, self.objc_class.superclass is still MyA, so MyA.init is called again. This continues forever.

And here's what should happen:

• self is an object of class MyB.
• When self.init() is called, the runtime searches for an init method in self.objc_class, i. e. MyB. That method exists, so it is called.
• MyB.init calls send_super(MyB, self, "init"). Rubicon asks the runtime to call self.init() and start method lookup in MyB.superclass, i. e. MyA. That method exists, so it is called.
• MyA.init calls send_super(MyA, self, "init"). Rubicon asks the runtime to call self.init() and start method lookup in MyA.superclass, i. e. NSObject. That method exists, so it is called.
• NSObject.init does its thing. No infinite recursion!

This issue is a bit difficult to explain, hence the long explanation. I hope it's somewhat understandable - if you have any questions, please ask!

from rubicon-objc.

Oh man you are awesome, dgelessus. So rarely do I interact with people on github that are so communicative and great. Thanks for this explanation.

I think I intuitively understood what you are explaining as I read through the runtime.py code and eventually "got" it.

But seeing it all laid down clearly surely elevates the discussion.

runtime starts searching for implementations in the superclass of the current class,

How exactly is it implemented in objective-c? From my quick reading -- basically the compiler generates an objc_super structure at compile time right there in the method when it sees the 'super' keyword -- so the super keyword always goes withe the concrete compile time class implementation the method finds itself in. (Which expains weirdnesses like [super class] not returning what you expect. It still returns [self class] such that [super class] == [self class]).

Clever!

We can't easily do the same in Python.. or can we?

Anyway -- I'd like very much to volunteer to fix this at some point (in addition to my promise to make ObjCBlock and Block and ObjCBlockInstance one and the same class that does everything).

How would we go about doing this properly? I guess I need to read the runtime.py code more and maybe something will pop into my head as an obvious solution. I feel like it may be possible to do it with minimal overhead.

If objc can do it by issuing a struct at compile-time that goes with a method -- surely we can do it at runtime somehow!

from rubicon-objc.

Update: I am reading the code now. Actually the 'super' obvious (pun intended) solution would just be to have send_super accept a new keyword argument in addition to the argtypes= and restype= keywords.. namely, 'objcsuper=' or somesuch, which instructs it where to start searching on the obj-c side for the superclass. objcsuper= should be an object of type ObjCClass, right? (Or perhaps the lower-level pointer type you get from get_class(name) )??

I am thinking that pretty much reproduces the 'automatic' functionality the obj-c compiler gives obj-c programmers, just we have to do it manually in python.

If the caller omits the arg, then the usual broken thing happens. If they add the arg, then the correct behavior occurs.

What do you think?

from rubicon-objc.

Ok, added a pull request, #108

Note: Quick and dirty but at least correct (I think!) approach. Let me know!

from rubicon-objc.

Oh man you are awesome

Thank you :)

How exactly is it implemented in objective-c? From my quick reading -- basically the compiler generates an objc_super structure at compile time right there in the method when it sees the 'super' keyword -- so the super keyword always goes withe the concrete compile time class implementation the method finds itself in.

Yep, that is correct. When you call a method on super, the compiler generates a call to objc_msgSendSuper instead of objc_msgSend. The first argument to objc_msgSendSuper is a struct objc_super *, and that struct contains two fields: receiver (the object to call the method on) and super_class (the class at which to start searching for the method). super_class is set at compile time to the superclass of the current class.

Which expains weirdnesses like [super class] not returning what you expect.

Yeah, it would be nice if [super class] returned the superclass of the current class or something, but it actually does the same as [self class]. By calling [super class] you're saying "call [self class] and ignore any implementation in this class", so unless your class defines its own class method, it won't make any difference.

Ok, added a pull request

Wow, that was quick! Will have a look.

from rubicon-objc.

Addressed in #108 — closing. Thanks for the help and everything with this!

from rubicon-objc.