Re: [Pyobjc-dev] More on integer values

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

We need unit tests.  David:   do you have a test case that demonstrates 
the mishandling of integers with NSUndoManager?

If you could send it to me, I will integrate it into the 
test_nsundomanager.py in Lib/Foundation/test/.

A unit test demonstrating the problem will ensure that we are all 
talking about the problem using the same vocabulary and expectations.

On Monday, Feb 3, 2003, at 02:13 US/Eastern, Ronald Oussoren wrote:
> Not too hard. There are (at least) two possible solutions:
>
> - David could use objc.selector to specify a signature that is more to 
> its liking (e.g. one of the
>   arguments is an int instead of an object). I don't really like this, 
> mostly because of the arcane
>   interface of selector()

Wouldn't this require applying the objc.selector() to the undo manager? 
   That seems problematic for a number of reasons.   Of course, if David 
were to subclass NSUndoManager and apply the objc.selector() calls to 
that subclass, it wouldn't be a problem.

I.e.:

class FundoManager(NSUndoManager):
     setColorCount_ = objc.selector(None, selector="setColorCount:", 
signature="v@:i")

If that is the case, it is a bummer, but not altogether too ugly save 
for the 'signature' argument.   If we were to declare a handful of our 
own types, the signature could be defined as an array of type objects.  
Something like:

     signature = [VoidType, IDType, SelectorType, IntType]

Actually, it really should be two different arguments to selector():

     objc.selector(None, selector="setColorCount:", returnType=VoidType, 
argumentTypes=[IntType])

We can drop the IDType and SelectorType specs because every selector 
must take (id) and (SEL) as the first two arguments.

> - We could treat NSNumber like a Python number when translating 
> arguments to Objective-C values. Doing
>   that would not be too hard. Or we could translate NSNumbers to 
> Python numbers when translating from
>   Objective-C values to Python values, but I don't think we should do 
> that.

[For the following, the exact same discussion could be applied to 
floats/doubles]

There are two distinct problems associated with handling integer types 
as a result of their being three different means of encapsulating an 
integer within a PyObjC based application.   There is the native C 
(int) type, a Python IntType, and NSValue/NSNumber instances.

The first problem is associated with converting (int) to Python 
IntTypes and back.   This generally works fine in the current code 
base.  Where it falls apart is in cases like the one David is 
describing with NSUndoManager.  That is, when a method that takes an 
integer argument is invoked through the bridge against a proxy object 
that does not contain the signature of the method to be invoked.

If the aforementioned potential fix doesn't work, I'm not sure what 
will.

The second problem involves the bridging of NSNumber into Python 
numbers and vice versa.   Currently, this doesn't appear to be broken.  
It is also not an issue in the context of David's problem.   There may 
be some subtleties that could be cleaned up in this context, though.   
As mentioned in the "autobridging by conversion" message, it may be 
useful to create a custom subclass of NSValue that can encapsulate the 
various Python number types.  This would allow us to preserve the 
python instance when a number comes back across the bridge.  Not only 
does this increase transparency of the bridge, but it may also reduce 
memory footprint and increase performance [in that we would just 
recycle the python instance coming back].

b.bum