Re: State based on front most document (was RE: Documentation frustrations)
Re: State based on front most document (was RE: Documentation frustrations)
- Subject: Re: State based on front most document (was RE: Documentation frustrations)
- From: Erik Buck <email@hidden>
- Date: Mon, 11 Jul 2005 18:50:36 -0400
Going back to the previous topic for a moment, this is an excellent
example
of what's wrong with the docs. "update" (with the corresponding
notification) is a great way to keep interface coordinated,
enabling and
disabling interface items as the user clicks here or there. But the
docs
don't explain this; I would never in a million years have thought
of this
myself. The way I know it is because someone (maybe Erik) told me
years ago.
It's the difference between a descriptive and a generative grammar:
the docs
tell you in technical terms what "update" does, but they do not
tell you
what you would use it for.
Why do you say you would never have thought of this ? Apple can't
document every possible use of every method. They can't even
document every common use, and who is to say what is common anyway ?
Programmers do need to have imagination and the ability to dream of
new uses for documented framework capabilities and an interest in
trying things :)
A quick search of Apple's example code on my disk reveals that there
are no examples on my disk that use -update:. It used to be that
Draw.app, the predecessor to Sketch.app, used -update: and
TextEdit.app probably did too. It is slightly ironic that by
providing automatic menu validation, a document architecture, and
other features in the framework, Apple may have inadvertently
obscured lower level techniques. That is one reason "Cocoa
Programming" substantially re-implements the document architecture in
an example. We wanted to pull the curtain back and show that there
is no magic happening.
Apropos of nothing: I get the feeling that people learning CoreData
are trying to use it for everything and are no longer even
considering the sometimes more appropriate alternatives provided by
the frameworks.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden