Re: the bloody Omni frameworks
Re: the bloody Omni frameworks
- Subject: Re: the bloody Omni frameworks
- From: "Timothy J. Wood" <email@hidden>
- Date: Sun, 4 Aug 2002 12:11:52 -0700
On Sunday, August 4, 2002, at 11:40 AM, James Winetke wrote:
That said, I've been wracking my brains, and I can't come up with the
scenario in which Project Builder's behavior here is anything but
broken.
This is useful to us (and many other developers) since we always want
a development tree and an install tree.
The only thing that should go in ~/Library/Frameworks are production,
installed frameworks. The reason it is in your home directory is so
that you can (for example) install FrontBase in your home directory and
have the FBAccess framework there for your personal use w/o disturbing
any other users that may have a different version installed.
~/Library/Frameworks is not intended to be used for holding builds of
development projects you are working on -- this is what the PB
preference for a build output directory is for. In fact, if you are an
application developer, you should almost never have need to put
anything in the Frameworks directory -- instead, stuff should go in the
app wrapper with @executable_path. Exceptions are things like
FrontBase which ship bare frameworks to clients.
Clearly, you are free to use your ~/Library/Frameworks for whatever
you want, but hopefully you'll find the above rational helpful.
I can't buy that reasoning. Real programmers write documentation, if
not
prior to coding. Relying on code comments is for dilettantes.
We certainly would like to have more documentation and we do have
some (some in autodoc format, some in internal design stuff). There is
a great deal of truth in ObjC being fairly self documenting when
written well. Even then, there are certainly parts of our frameworks
that are extremely powerful and not terribly transparent to the first
time user (OWPipeline comes to mind :). These are the parts that
really deserve documentation.
That said, this code has been made available to people for free.
It's a real world code base that solves real problems for real
*shipping* applications. It can always be better, and we certainly aim
to make it better in the future (Omni has a full-time test engineer
starting soon, for example that will be doing some documentation work
as well as producing regression tests, etc).
-tim
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.