pyobjc-dev

[Pyobjc-dev] DictType -> ObjC

[Bill B. <bb...@co...>]

Ronald,

     How hard would it be to proxy DictType, ArrayType, and TupleType 
into Obj-C such that they look/feel/act/behave/are subclasses of 
NSDictionary and NSArray?

     That is, such that they implement the primitive methods of the 
NSDictionary/NSArray class clusters and internally use the Py* APIs to 
retrieve/set values [converting as necessary]?

     This would be significantly valuable in that it doesn't imply a 
conversion as the objects come across the bridge from Python->ObjC, yet 
they would be compatible with NSDictionary/NSArray and friends.

     Also-- should the following slice fail in the way that it does?  (I 
included the last two lines only because it raises the question as to 
whether or not NSNumber/NSValue should be converted across the bridge 
-- I'm not sure that there is a really clear answer).

[bumbox:IssueCenter/V3/Python] bbum% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> x = NSMutableArray.array()
 >>> x.addObject_(1)
 >>> x.addObject_(2)
 >>> x.addObject_(3)
 >>> x.addObject_(4)
 >>> x.addObject_(5)
 >>> y = [1,2,3,4,5]
 >>> y[2:4]
[3, 4]
 >>> x[2:4]
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.2/site-packages/objc/__init__.py", line 152, 
in <lambda>
     CONVENIENCE_METHODS['objectAtIndex:'] = ('__getitem__', lambda 
self, arg: self.objectAtIndex_(arg))
TypeError: expected an integer for argument 1: its typespec is 'I'
 >>> y[0]
1
 >>> x[0]
<NSCFNumber objective-c instance 0xc1a7c0>
 >>>


     b.bum

Re: [Pyobjc-dev] DictType -> ObjC

[Jack J. <Jac...@or...>]

On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:

>     How hard would it be to proxy DictType, ArrayType, and 
> TupleType into Obj-C such that they look/feel/act/behave/are 
> subclasses of NSDictionary and NSArray?
>
>     That is, such that they implement the primitive methods of 
> the NSDictionary/NSArray class clusters and internally use the 
> Py* APIs to retrieve/set values [converting as necessary]?
>
>     This would be significantly valuable in that it doesn't 
> imply a conversion as the objects come across the bridge from 
> Python->ObjC, yet they would be compatible with 
> NSDictionary/NSArray and friends.

Will these objects still be compatible with CoreFoundation? I'm 
not familiar enough with how Apple made CF and NS objects 
interchangeable, but if Pyobjc would handle most objects not by 
actually converting them but by putting them in something that 
merely "looks/feels/acts/behaves" like the real NS class that 
may not be good enough. I assume that "are" is good enough, but 
again I'm not sure.
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -

Re: [Pyobjc-dev] DictType -> ObjC

[Bill B. <bb...@co...>]

On Thursday, October 17, 2002, at 04:32 PM, Jack Jansen wrote:
> On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:
>>     How hard would it be to proxy DictType, ArrayType, and TupleType 
>> into Obj-C such that they look/feel/act/behave/are subclasses of 
>> NSDictionary and NSArray?
>>
>>     That is, such that they implement the primitive methods of the 
>> NSDictionary/NSArray class clusters and internally use the Py* APIs 
>> to retrieve/set values [converting as necessary]?
>>
>>     This would be significantly valuable in that it doesn't imply a 
>> conversion as the objects come across the bridge from Python->ObjC, 
>> yet they would be compatible with NSDictionary/NSArray and friends.
>
> Will these objects still be compatible with CoreFoundation? I'm not 
> familiar enough with how Apple made CF and NS objects interchangeable, 
> but if Pyobjc would handle most objects not by actually converting 
> them but by putting them in something that merely 
> "looks/feels/acts/behaves" like the real NS class that may not be good 
> enough. I assume that "are" is good enough, but again I'm not sure.

Yes -- it is simply a matter of implementing the appropriate primitive 
methods for each class [for class clusters]:

#import <Foundation/Foundation.h>
#import <CoreFoundation/CoreFoundation.h>

@interface FooArray:NSArray
id stuff[100];
@end
@implementation FooArray
- init
{
   [super init];
   int i;
   for(i = 0; i < 100; i++) stuff[i] = [[NSNumber numberWithInt: i] 
retain];
   return self;
}
- (id) objectAtIndex: (int) anIndex { return stuff[anIndex]; }
- (unsigned) count { return 100; }
@end

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   FooArray *fooArray = [[FooArray alloc] init];
   NSLog(@"objectAtIndex: 76 -- %@ - 0x%x",
		    [fooArray objectAtIndex: 76],
		    [fooArray objectAtIndex: 76]);
   CFArrayRef fooRef = (CFArrayRef) fooArray;
   NSLog(@"CFArrayGetValueAtIndex(..., 76) -- %@ - 0x%x",
		    CFArrayGetValueAtIndex(fooRef, 76),
		    CFArrayGetValueAtIndex(fooRef, 76));
   [pool release];
   return 0;
}

Outputs:

2002-10-17 16:54:06.121 arraytest[23625] objectAtIndex: 76 -- 76 - 
0x59a80
2002-10-17 16:54:06.122 arraytest[23625] CFArrayGetValueAtIndex(..., 
76) -- 76 - 0x59a80

The same can generally be said/done with any no-cost bridged object, 
just that it may require more methods to be implemented.

In any case, a PyArray subclass simply has to provide implementations 
of -objectAtIndex: and -count:.  All other methods in the NSArray API 
are implemented against those two primitive methods.   The CF "no cost" 
bridge is truly a "no cost" bridge -- it just calls the method IMPs 
directly (not sure how it looks 'em up).

The source to the CF<->NS 'no cost' bridge is in the Darwin CVS 
repository -- CFBase, I believe.

b.bum

Re: [Pyobjc-dev] DictType -> ObjC

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

On Thursday, Oct 17, 2002, at 22:58 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Thursday, October 17, 2002, at 04:32 PM, Jack Jansen wrote:
>> On donderdag, oktober 17, 2002, at 01:12 , Bill Bumgarner wrote:
>>>     How hard would it be to proxy DictType, ArrayType, and TupleType 
>>> into Obj-C such that they look/feel/act/behave/are subclasses of 
>>> NSDictionary and NSArray?
>>
>> Will these objects still be compatible with CoreFoundation? I'm not 
>> familiar enough with how Apple made CF and NS objects 
>> interchangeable, but if Pyobjc would handle most objects not by 
>> actually converting them but by putting them in something that merely 
>> "looks/feels/acts/behaves" like the real NS class that may not be 
>> good enough. I assume that "are" is good enough, but again I'm not 
>> sure.
>
> Yes -- it is simply a matter of implementing the appropriate primitive 
> methods for each class [for class clusters]:
[removed example]

Great. Actually adding these collection proxies is fairly trivial.

With a just commited version of python:
from Foundation import NSMutableArray

a = NSMutableArray.alloc().init()
a.addObject_(1)
a.addObject_({'hello':'world'})
a.addObject_([3, 4, 5])
print "The array:", type(a), a
print "a[0]:", type(a[0]), `a[0]`
print "a[1]:", type(a[1]), `a[1]`
print "a[2]:", type(a[2]), `a[2]`

Gives:

The array: <objective-c class NSCFArray at 0x30ed70> (1, {hello = 
world; }, (3, 4, 5))
a[0]: <objective-c class NSCFNumber at 0x2d7550> 1
a[1]: <type 'dict'> {'hello': 'world'}
a[2]: <type 'list'> [3, 4, 5]


Note that a[1] and a[2] are printed like NSDictionary and NSArray 
objects while in the NSMutableArray.

Ronald