pyobjc-dev

[Pyobjc-dev] Bug in objc.synthesize

[Dirk S. <dir...@ma...>]

Hi all,

We've been trying to use the objc.synthesize method in our project,  
but ran into some issues with it.

After peeking in pyobjc-core for a bit, I think I might have found a  
bug.

At line 186 and beyond (def synthesize), in:
> http://svn.red-bean.com/pyobjc/trunk/pyobjc/pyobjc-core/Lib/objc/_descriptors.py


, the generated setter strings use name.capitalize() to go from 'ivar'  
to 'setIvar_'.  This works as expected on variable names with only  
lowercase characters, but has an undesired effect on names with  
camelCase in them.

examples:
name = 'string'
resulting setter method name = 'setString_'

name = 'searchString'
resulting setter method name = 'setSearchstring_'
expected setter method name = 'setSearchString_'

If we replace:
> name=name.capitalize()

with:
> name = '%s%s' % (name[0].upper(), name[1:])


It should be fixed, but using the [1:] indexset means that an  
IndexError will be thrown for names with zero length. (Though that  
doesn't sound like a big deal to me, we might want to provide a better  
description than 'index out of range' when that happens).

I can't build from trunk right now, so it's a bit of a hassle for me  
to actually test this fix, hence this email instead of a patch.

@Ronald: Please let me know if you want to hear about specific  
problems building on 10.5 right now, (or if you'd like me to submit  
patches with fixes for those problems, let me know how you prefer  
those patches to be formatted).

Thanks :)
- Dirk

Re: [Pyobjc-dev] Bug in objc.synthesize

[Ronald O. <ron...@ma...>]

On 12 Jul, 2009, at 15:32, Dirk Stoop wrote:

> Hi all,
>
> We've been trying to use the objc.synthesize method in our project,
> but ran into some issues with it.
>
> After peeking in pyobjc-core for a bit, I think I might have found a
> bug.

Good catch. That's my punishment for not adding unittests for this  
feature...

>
> @Ronald: Please let me know if you want to hear about specific
> problems building on 10.5 right now, (or if you'd like me to submit
> patches with fixes for those problems, let me know how you prefer
> those patches to be formatted).

I'm interested in both bugreports and patches. I'd prefer patches in  
unified diff format ('diff -u', or the default output of 'svn diff').

My laptop is currently running a SL preview and I'm not testing on  
Leopard at the moment.

Ronald

Re: [Pyobjc-dev] Bug in objc.synthesize

[Ronald O. <ron...@ma...>]

W.r.t. objc.synthesize: I've been experimenting with Python's  
"property" function as a decorator. In Python 2.6 you can do something  
like this:


class MyClass (object):

      @property
      def stringValue(self):
           return self._value


      @stringValue.setter
      def setStringValue(self, value):
            self._value = value


It should be doable to do something simular for objc properties, such  
as:


class MyController (NSObject):

       stringValue = objc.property(rw=True, copy=True,  
ivar='_stringValue')

       @stringValue.getter
       def get(self):
             return self._stringValue

objc.property would define an ivar and getter and setter methods.  
Those methods would only be visible on the ObjC side, Python users  
always access the property using regular attribute access (the bridge  
would also ensure that the correct selectors are used for the accessor  
methods, regardless of the name used in the Python code).

With some effort this could be extended to add other KVC/KVO related  
methods where needed, such as an objc.set_property that uses an  
NSMutableSet as the backing storage and ensure that manipulation of  
the set is done using the right KVC accessor methods.

As sketched above this would need some support in the C code,  
simularly to how objc.ivar is handled.  I do think this could be a  
useful addition to PyObjC, and will try to find some time to write a  
proper specification and testsuite for this (followed by an  
implementation once we're happy about the first two).

The scary future scenario for this is to expose existing ObjC  
properties using the same mechanism. This is "scary" because doing  
this is incompatible with existing code, and hence something I'd only  
implement once the basic support is stable (and included in a  
release). With some luck lib2to3 (the python2.x to 3.x translation  
tool) can be coaxed into translating the current syntax  
(aField.setStringValue_(v)) to the new syntax (aField.stringValue =  
v), but that's something I'll look into when its needed.

Ronald

Re: [Pyobjc-dev] Bug in objc.synthesize

[Barry W. <bar...@gm...>]

+1!


On Mon, Jul 13, 2009 at 12:08 PM, Ronald Oussoren<ron...@ma...> wrote:
>
> W.r.t. objc.synthesize: I've been experimenting with Python's
> "property" function as a decorator. In Python 2.6 you can do something
> like this:
>
>
> class MyClass (object):
>
>      @property
>      def stringValue(self):
>           return self._value
>
>
>      @stringValue.setter
>      def setStringValue(self, value):
>            self._value = value
>
>
> It should be doable to do something simular for objc properties, such
> as:
>
>
> class MyController (NSObject):
>
>       stringValue = objc.property(rw=True, copy=True,
> ivar='_stringValue')
>
>       @stringValue.getter
>       def get(self):
>             return self._stringValue
>
> objc.property would define an ivar and getter and setter methods.
> Those methods would only be visible on the ObjC side, Python users
> always access the property using regular attribute access (the bridge
> would also ensure that the correct selectors are used for the accessor
> methods, regardless of the name used in the Python code).
>
> With some effort this could be extended to add other KVC/KVO related
> methods where needed, such as an objc.set_property that uses an
> NSMutableSet as the backing storage and ensure that manipulation of
> the set is done using the right KVC accessor methods.
>
> As sketched above this would need some support in the C code,
> simularly to how objc.ivar is handled.  I do think this could be a
> useful addition to PyObjC, and will try to find some time to write a
> proper specification and testsuite for this (followed by an
> implementation once we're happy about the first two).
>
> The scary future scenario for this is to expose existing ObjC
> properties using the same mechanism. This is "scary" because doing
> this is incompatible with existing code, and hence something I'd only
> implement once the basic support is stable (and included in a
> release). With some luck lib2to3 (the python2.x to 3.x translation
> tool) can be coaxed into translating the current syntax
> (aField.setStringValue_(v)) to the new syntax (aField.stringValue =
> v), but that's something I'll look into when its needed.
>
> Ronald
>
>
>
>
> ------------------------------------------------------------------------------
> Enter the BlackBerry Developer Challenge
> This is your chance to win up to $100,000 in prizes! For a limited time,
> vendors submitting new applications to BlackBerry App World(TM) will have
> the opportunity to enter the BlackBerry Developer Challenge. See full prize
> details at: http://p.sf.net/sfu/Challenge
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>