On Feb 7, 2005, at 12:10 PM, Tom Insam wrote:
> It's runtime - there's a line at the beginning of the source file:
> this is defined in
Okay, that's pretty simple. classes.nib is just a plist, so it's a
one-liner to get its contents into a hash.
The more I look into this, the more obvious is becomes - reading class
definitions from nibs would be a useful option to provide. But it's
also increasingly obvious that it can't be the *only* way to define
classes - standalone .pl scripts, apps that use GORM or Renaissance
interfaces, etc. won't have nibs.
So, the way forward is pretty clear - separate the interface(s) from
the implementation. I need to write this class() function, but it
shouldn't do any of the real work. Instead, it will simply parse its
arguments and call low-level functions that do the work. The
extractNibClasses() function would behave similarly, parsing
classes.nib and calling those same low-level functions to register the
classes, create accessor methods, etc.
Thanks for the comments - it's been a real help getting the design
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org