Re: File's Owner

FROM : Andy Lee
DATE : Sun May 25 15:31:21 2008

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.