Re: [Pyobjc-dev] NibLoader.py: parsing nibs at runtime

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

On Saturday, Nov 16, 2002, at 23:31 Europe/Amsterdam, bb...@ma... 
wrote:

> On Saturday, November 16, 2002, at 05:19 PM, Just van Rossum wrote:
>> bb...@ma... wrote:
>> [ great explanation snipped ]
>>
>>> For Outlets, the connection process simply sets the instance variable
>>> directly, if possible.   However, before doing so, it checks to see 
>>> if
>>> the object contains the method setOutletName: and, if so, calls that
>>> method instead, passing the object that it will be connected to as 
>>> the
>>> first argument (i.e. if ExampleObject implemented -setRandomObject: 
>>> it
>>> would be called instead of just making a direct connection).
>>
>> Ok, so the _runtime_ will add instance variables?
>
> [talking pure ObjC here] No -- in the case where -setRandomObject: is 
> implemented, there need not be an instance variable named randomObject 
> at all.   The connection mechanism assumes that since the developer 
> implemented the -set*: method, the developer is going to take care of 
> doing whatever they want/need with the object passed to the method.

Is this documented somewhere. I knew that the NSNibLoader class does 
something like this, but I didn't find information about it in the 
documentation at the time (early this summer, when Jack surprised me by 
using outlets when I was sure I hadn't added support for them yet)
>
> Ahhh... now I understand.   From the Python-Cocoa template, I see the 
> declaration of....
>
>   messageTextField = IBOutlet("messageTextField")
>
> ... but, in the implementation, I see...
>
>     self.messageTextField.setStringValue_( helloString )
>
> ... so, yes, it appears that IBOutlet() creates a declaration for an 
> ivar that is then shared among all classes.  Yet, each individual 
> instance gets its own instance variable slot for that particular ivar.

This is indeed true. IBOutlet does two things
1. It causes an instance variable to be added to the Objective-C side 
of the new class.
2. It defines a property for accessing this instance variable.

It is using the same mechanism as class property(object)
  |  property(fget=None, fset=None, fdel=None, doc=None) -> property 
attribute
  |
  |  fget is a function to be used for getting an attribute value, and 
likewise
  |  fset is a function for setting, and fdel a function for del'ing, an
  |  attribute.  Typical use is to define a managed attribute x:
  |  class C(object):
  |      def getx(self): return self.__x
  |      def setx(self, value): self.__x = value
  |      def delx(self): del self.__x
  |      x = property(getx, setx, delx, "I'm the 'x' property.")
  |

Ronald

P.S. Does anyone have a 'mailinglist-archive-to-documentation script? 
The mailinglist archives currently contain more usefull information 
than the documentation in the source archive.