Re: [Pyobjc-dev] NIB Validation & action methods

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

On Tuesday, November 19, 2002, at 01:20 AM, Ronald Oussoren wrote:
> On Monday, Nov 18, 2002, at 16:01 Europe/Amsterdam, bb...@ma... wrote:
>
>> On Sunday, November 17, 2002, at 02:06 AM, Ronald Oussoren wrote:
>>> In Python you can also add new methods to a class. I'd not worry to 
>>> much about this, if only because it will be less efficient to call 
>>> those additional methods from Objective-C: The additional methods 
>>> are called through an NSInvocation while the normal methods are 
>>> called through more efficient method stubs.
>>
>> Efficiency of dispatch in this context is largely irrelevant as it 
>> generally happens as a part of the user clicking a button or hitting 
>> a menu item -- i.e. once to trigger the event processing.
>
> It is not entirely irrelevant, some methods in the NSTableDataSource 
> are called quite often and if those are slow this is noticable.

Yes;  Speaking of.... when are NSTableDataSource methods validated?  
... at Nib load or when the table goes to the datasource the first time?

I would consider it a performance issue that we have to go through 
NSInvocation in this situation -- a bug, really -- but I'm not at all 
sure there is anyway around it?

>> Given that action method validation already exists within the AppKit 
>> framework and it works at the only time where complete/correct 
>> validation is possible, why should we bother duplicating that 
>> functionality in the PyObjC module and doing so in a fashion that is 
>> going to generate false warnings?
>
> It might generate false warnings if the Python code adds new methods 
> at runtime. Whenever I do things like that I prefer not to depend on 
> automatic mechanisms likes Just's AutoBaseClass.

Agreed.

> The other 'false' warnings are generated when actions have been 
> defined in Interface Builder that are not yet used. I don't think 
> these are false warnings at all, either the UI does not yet use the 
> actions (e.g. this is a development version) or you're building up 
> cruft in your NIB file.

Agreed -- and they are warnings that will be covered when the NIB is 
loaded, so why reinvent the wheel?

I often use the warnings that the Cocoa NIB loading mechanism emits as 
a kind of bookmark for functionality that needs to be implemented.  
This is a big part of the reason why I don't think that the 
AutoBaseClass on-the-fly class definition should define placeholders;  
they effectively disable already working validation, move the 
validation to a location that an experienced Cocoa programmer will not 
expect, and raise the situation of potentially false validation 
warnings.

b.bum