Re: [Pyobjc-dev] Re: Making List<->Array bridging transparent

[Ronald O. <ous...@ci...>]

On Saturday, Nov 9, 2002, at 15:42 Europe/Amsterdam, Peter Montagner 
wrote:

>
> On Sunday, November 10, 2002, at 01:11 AM, Ronald Oussoren wrote:
>
>>
>> On Saturday, Nov 9, 2002, at 11:31 Europe/Amsterdam, Peter Montagner 
>> wrote:
>>
>>> Bill Bumgarner wrote:
>>>
>>>>  ... is true, then we add <type 'list'> to the bases for the newly
>>>> created Python class object?   Assuming a complete implementation of
>>>> convenience methods, this would allow bridged instances of NSArray 
>>>> to
>>>> function fully on the Python side of the bridge [i.e. work in 
>>>> contexts
>>>> like the above where the runtime is testing for a particular type 
>>>> and
>>>> not just a set of methods].
>>>>
>>>> As an experiment, I tried-- naively-- to add this to the function 
>>>> that
>>>> bridges classes to Python... it doesn't work.
>>>
>>> So you can't do it by adding list as a base but could you instead 
>>> just not use ObjCObject to do the wrapping? What if you created 
>>> another class with list as the only base? You can't slam 
>>> PyListObject and ObjCObject together but could you subclass list and 
>>> add real_object as another variable? Or will python not even let you 
>>> subclass compiled classes in C?
>>
>> That would work, but then NSArray would no longer by a subclass of 
>> NSObject. This will probably cause subtle bugs and won't buy us much 
>> in the long run. Especially because this will be a non-issue in 
>> Python 2.3: I filed a bug-report related to this and the bug was 
>> fixed within a day :-)
>
> Great! But why wouldn't NSArray be a subclass of NSObject under my 
> scheme? ObjCObject isn't an NSObject is it? I though it was a proxy, 
> passing method calls to an encapsulated id. I was thinking a list 
> based NSArray wrapper would act the same: answering any sequence 
> methods by translating them into NSArray methods and passing any non 
> sequence methods (ie. native NSArray methods) on to the encapsulated 
> NSArray. This way, any NSArray instances would look like sequences to 
> pure python code but would still respond to all the Cocoa methods as 
> per normal. Of course, I'm still pretty new to the inner workings of 
> PyObjC so I could be completely mistaken. And I have absolutely no 
> idea how hard that would be.

Don't forget that there are two sets of classes with the same name: The 
original Objective-C classes and the Python proxy classes. Currently 
the latter have the same inheritence graph as the former, with the 
addition of a single root: objc.objc_object. It would be possible to 
make the Python class NSArray a subclass of list, but then it can no 
longer be a subclass of objc.objc_object (imcompatible base classes). I 
just remembered that this wouldn't solve the list slicing problem on 
Python 2.2, because the list slicing code directly accesses the PyList 
representation (even if a subclass of list has overridden __getitem__).
>
> How is either method going to solve the splice problem if the splice 
> code is trying to access the list directly? Did I understand that 
> correctly?
Subclassing list doesn't help with Python 2.2. In Python 2.3 either 
method will work (not subclassing list actually works better at the 
moment, but that will be fixed soon). Given this situation I'd prefer 
to not change the base-class for NSArray.

>
> BTW, how long do you think it will take Apple to include Python 2.3 in 
> the default install?
Long. Apple seems to have a long feature-freeze for the Darwin part of 
new OSX releases and Python 2.3 has not even reached an alpha release 
at the moment, I wouldn't be surprised if Python 2.3 isn't released 
before the summer of 2003.

BTW. The alpha status of 2.3 doesn't mean that this version is 
unusable. I haven't really run into problems while using it the last 
couple of months.

Ronald