Re: [Pyobjc-dev] objc classes

[b.bum <bb...@ma...>]

On May 29, 2004, at 6:59 AM, Helge Hess wrote:
> On May 29, 2004, at 7:35, Ronald Oussoren wrote:
>>>> Further, would it possible to change the class hierarchy of an 
>>>> existing class? So that MyFormatter initially inherits from say 
>>>> NSFormatter and after reloading a Python module inherits from 
>>>> NSDateFormatter. Would that be possible with the Apple ObjC runtime 
>>>> or is this already possible with PyObjC?
>> It is not possible with PyObjC. It might be possible with the Apple 
>> ObjC runtime, but would be pretty hard using the GNUstep runtime 
>> (that one definitely maintains a list of subclasses).
>
> Well, the question is what the list of subclasses is actually used 
> for. I'm mostly concerned about "live editing" during development, ala 
> fix&continue, where the superclass changes (so hacks are great as well 
> ;-). If some subclass reflection doesn't work, it should be acceptable 
> I guess.
>
> Hm, I just wonder whether posing is just that or helps here?

The ObjC runtime does this as a part of +poseAsClass:   The original 
class is renamed to %Class and is made to be a super of the posing 
class (which is renamed to the original name of the Class).   KVO 
effectively does something similar.

PyObjC could certainly do the same and the source for +poseAsClass: is 
available in the darwin repository.

If the GNUStep runtime supports posing, it likely does something 
similar.

So, yes, you could change the class hierarchy at runtime as described 
and this could be used to do re-loading of classes while not impacting 
existing instances.   Since PyObjC internalizes instance variables, you 
could even change the instance variables across loads-- something that 
cannot be done without breaking binary compatibility in ObjC.

>> This limitation may be liften in a future version of PyObjC. 
>> Reloading can be useful during development.
>
> Exactly. I'm just thinking about development time where one has typed 
> in a scripted class in some editor and then rethinks about the 
> superclass.

WebScript did this in WebObjects and it rocked.  You could change the 
implementation and reload a web page to see the new behavior.

b.bum