Re: File's Owner
Re: File's Owner
- Subject: Re: File's Owner
- From: Andy Lee <email@hidden>
- Date: Sun, 25 May 2008 09:31:21 -0400
On May 25, 2008, at 6:20 AM, mmalc crawford wrote:
On May 25, 2008, at 12:15 AM, Johnny Lundy wrote:
And, if I don't understand something, I will ask why.
Here are some suggestions as to how you might pose your questions:
<http://www.catb.org/~esr/faqs/smart-questions.html>
I hesitate to re-enter this thread, I really do. But I think those of
us who have been trying to help might want to re-consider how we've
been answering, as well as how the questions have been posed. There
have been many fine, thorough answers to Johnny's question. The fact
that none of them have seemed to help should tell us something.
If I can make a rough analogy, many of our answers have been like
different re-implementations of an algorithm. Like the guy on the
guillotine in that engineer joke, we each think we see what the
problem is. And so we "recode" the algorithm our own way, "run" it --
i.e., post our new, improved explanation -- and find it still fails. [1]
I submit that instead of recoding the "explain File's Owner"
algorithm, other approaches might lead to a quicker resolution.
One alternative is a "printf" approach to narrowing down the problem.
Just as we often tell people to check that variables are what they
think they are (D'oh! -- forgot to set an outlet), it might help if we
state the relevant logic in *very fundamental* terms and have Johnny
indicate *at which point* in the logic he gets lost. This is the
approach I tried to take earlier, and although Johnny referred to a
line in the Apple docs rather than in my explanation, it led to a very
revealing question. He asked:
What other objects outside the nib?
To me this suggested a FUNDAMENTAL disconnect, possibly at a level
that precedes understanding File's Owner. If I were inclined to
follow up, I might ask:
* Do you now understand there can be objects outside the nib?
* Do you understand that your application creates objects, including
the application instance, *before* loading MainMenu.nib?
* Do you understand that you might want to create and load a nib other
than MainMenu.nib?
* Do you understand that you may have an object X of your own in your
application just *before* you load your nib?
* Do you understand that loading the nib will create a bunch of new
objects A, B, and C?
* Can you imagine that you'd want X to connect to one or more of A, B,
and C?
Besides the "printf" approach, another possibility might be a
"homework" approach: write an application that does X, where X
highlights the reason for File's Owner. This would require extensive
personal followup -- perhaps something a tutor could offer to do for
pay.
This is not magic - there is actual computer code behind that
File's Owner concept, and it is deterministic, not vague, not
abstract, not a philosophical enigma, not random, not ambiguous. If
I had the source code I could see what it does.
But that's where you're leading yourself astray -- there isn't any
source code to see. The nib file is an object graph with a hole in
it.
I assumed Johnny meant the source code that *reads* the nib. I
personally don't believe that would help.
The File's Owner is the hole -- the one thing that *isn't* created
in the nib.
First Responder and Application are also not created in the nib. :)
Despite teaching OB/GYN for 17 years, this is why computer science
is always my main interest.
Perhaps it's your background that's causing you the problem. My
father was Dr. J. Selwyn Crawford. I persuaded him to buy a Mac in
1986. He somehow failed to understand (a rarity) that when you use
a word processor you don't have to put Returns at the end of the
line...
It's true we all have different blind spots.
I've written firmware before we called it firmware. I have never
NOT been able to grasp something until this and bindings. Aaron
says lots of people have trouble understanding File's Owner, so I
can only conclude that it's the documentation, or lack thereof.
I think this is a fallacious conclusion.
It is a fallacious conclusion for many reasons, one of which is that
it also discounts the many sincere efforts of people on this list who
have tried to help.
--Andy
[1] BTW, I am aware of the dangers of using computer concepts as
models for human reasoning and human interactions. Take this analogy
only for what it's worth.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden