On 2 Sep 2015, at 8:29 AM, Thomas Wetmore <[email protected]> wrote:
> In the IB editor, looking at the new XIB file, the class of the File’s Owner
> is identified as the new NSWindowController subclass. As expected.
>
> But if I right click on the File’s Owner icon (or the window’s icon), I see
> two connections already set up:
>
> 1. The window’s delegate outlet points to the File’s Owner.
> 2. The File’s Owner has a window outlet pointing to the window.
>
> My confusion comes from the fact that NSWindowController does not have a
> window outlet (that I can find documented),
NSWindowController.h:110 as of Mac OS X 10.10.5:
> @property (strong) NSWindow *window;
Nothing for the compiler to complain about. (You’ve already reported that you’d
figured that out, but that message wasn’t a reply to this one. I’m making a
record so your question has a searchable reply in the archives.)
> nor does the NSWindowController implement the NSWindowDelegate protocol.
In the sense of being declared an <NSWindowDelegate>, you’re right. I can’t
immediately think why it isn’t declared, but there it is.
In the sense of implementing all the required methods of <NSWindowDelegate>,
NSWindowController vacuously complies: None of the delegate protocol methods
are required, so every class meets the requirements. Back in the days when
protocol compliance was strictly a matter of duck typing, that was enough.
In these days, I see that the delegate property in NSWindow is declared
id<NSWindowDelegate>. That would be a problem in code, because the compiler
would at least warn on assignment from an object that is not declared to
comply. However…
> Why doesn’t the compiler complain about these two things?
1. There would not be a complaint about the missing window property, because
there it is.
2. There would be a complaint about the lack of (declared) protocol compliance
because this is Interface Builder, not a compiler.
The link is _defined_ in the NIB, where IB doesn’t care what the definitions
are at the time the connections are made.
The link is _used_ when the NIB is loaded at runtime. IB is perfectly happy to
link to outlets and classes that don’t exist, or don’t implement required
methods. The first time you’ll know about them is when your application crashes
for lack of the requested classes and properties.
The compiler isn’t involved, so it never has a chance to compare links to
declared types. It might be an interesting feature to have llvm audit the NIBs
before Xcode attempts to run the app, but for now that’s an Exciting Future
Direction.
— F
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/xcode-users/archive%40mail-archive.com
This email sent to [email protected]
