Re: [Pyobjc-dev] Default to returning (void)?

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

On 16-feb-04, at 6:11, Bob Ippolito wrote:

> On Feb 16, 2004, at 12:00 AM, b.bum wrote:
>
>> On Feb 15, 2004, at 8:36 PM, Bob Ippolito wrote:
>>> At least in Python 2.3.x, the only way to generate "LOAD_CONST 0 
>>> (None) / RETURN_VALUE" is either a bare return, or no return at all. 
>>>  If you analyze the bytecode for a function, and it has no other 
>>> RETURN_VALUE pairs.. then you can safely assume that it should 
>>> default to void.
>>
>> Eeeewwwww....
>>
>> Nuts.   Defaulting to  a (void) return will break for any getter, so 
>> I can see how trying to figure this out to do the right thing would 
>> be preferable.
>
> Yeah, it's gross, but analyzing the bytecode *would* work ;)

This is a little too magic, although it is a neat hack :-)

>
>> Barring automated intelligence, being able to do something like the 
>> following would be preferable to the crypting exposed signatures we 
>> have today.
>>
>>     def setContent_(self, someContent):
>>         print "Setting content...."
>>         self._content = someContent
>>     setContent_ = selector(setContent_, type='setter')
>> 	objc.makeSetter(setContent_) # this would be even better
>>
>> 	def takeAction_(self, sender):
>> 		pass
>> 	takeAction_ = selector(takeAction_, type='action')
>
> Why not objc.getter / objc.setter / objc.action?  This is really why 
> Python needs a way to decorate functions that isn't so f*!@#!ing ugly.

or objc.IBAction, which has the advantage of already existing.

Changing the default is unacceptable, this would break people's code 
without any real advantage, they would have to add annotations to the 
other half of their methods.  The current semantics are also 
comptatible with Python itself.

Ronald
--
X|support bv            http://www.xsupport.nl/
T:  +31 610271479       F:  +31 204416173