NSWindow class that allocs its own controller?

FROM : daniel
DATE : Wed Apr 06 20:19:34 2005

Should a class that is typically instantiated via a controller, e.g. an
NSWindow subclass that is managed by an NSWindowController, be made
capable of "instantiating its own controller"?

I am faced with this question in my attempt to add AppleScript support
for a controller-managed window class in my application. Cocoa
Scripting likes to instantiate objects directly by class name. In my
case, it's an NSWindow subclass that I ultimately want to expose to
AppleScript, but it's instantiated typically via an NSWindowController.

  Let's say FunWindowController manages a FunWindow whose interface is
contained in FunWindow.nib.

Ordinarily, to instantiate a FunWindow from code, I would allocate and
initialize a FunWindowController, which would in turn
"initWithWindowNibName" for FunWindow.nib.

To get "easy AppleScript support," I can define a FunWindow class in my
scripting definition and define it as a subclass of "window", with a
class name of "FunWindow."  The obvious problem here is that FunWindow
is incapable of instantiating itself.

So, I could add an "init" method to my FunWindow that releases self and
in its place returns a freshly created FunWindowController's window.
Yuck!  I would probably also have to detect a cycle since init would
probably re-enter as soon as FunWindowController created its window.

How do I do this correctly?  I asked about this on
AppleScript-Implementors but twice received a resounding silence.  Am I
missing something big here? I see a big disconnect between the
AppleScript object model and the Cocoa tendency to rely  on "helper
objects."  Hopefully somebody smarter than me (and who doesn't read
Applescript-Implementors) has dealt with this and can offer some
advice.

Thanks!
Daniel