Article:		Browsing Cocoa with F-Script
Subject:		remarks on topology
Date:		2001-12-21 21:46:21
From:		psheldon
This is an atta boy. I have an odd way of learning things. I like to be frustrated. Your remarks on topology seemed to be conceptualization of an axiomatic approach to the next step framework language. It frustrated me because I almost got it but not quite. Frustration is good. It motivates me to read the examples. Examples are good because I invariably get burned making mistakes and then I appreciate and learn the axioms better. So I am not complaining because I was frustrated. I can easily frustrate myself, but I am not always sure this will lead to knowledge and it is apparent that you know more than I here and I trust you more than myself to frustrate me. It is merciful to an author not to displace all my frustration onto him by asking why why why too soon because my confusion and frustration has to settle in for me to appreciate and be able to absorb an answer to all the why's. There is no royal road to mathematics. These remarks might be a gracious attempt to try to pare down some sort of EBNF grammar defining next step object system, if there is any EBNF grammer so defining it or it might be the first step to daring to try to write down such a grammar. I'm not ready, the author is not ready for why why why, but perhaps it is kind for me to say which is the most difficult axiom for me to allow myself to be frustrated with right now : "The fact that NSObject (meta) inherits from NSObject explains why instance methods defined for the root class are also class methods."

Showing messages 1 through 1 of 1.

• Some more remarks
  2001-12-26 05:50:53  pmougin [View]
  
  
  A key point is that the structure described is actually present, in memory, for each Objective-C program during run-time. The "is instance of" and "inherits from" relationship are represented by mere pointers. This structure is created and managed automatically by the Objective-C run-time.
  
  
  
  The main purpose of the in-memory representation of each class is to host a correlation table, which associates method names (in the form of selectors) with pointers to the actual compiled code of the methods. This is the basic information the messaging system needs in order to work.
  
  
  
  This table is of course based on the information that was given to the compiler in the source code. In particular, instance methods (which are syntactically marked by "-" at the beginning of their declarations in Objective-C source code) are referenced in the correlation table of the corresponding class. Class methods (which are marked with "+") are referenced in the correlation table of the corresponding meta-class.
  
  
  
  When a message is sent to an object, the run-time system exploit this structure in order to find the actual implementation of the method (the compiled code to execute). The first step is to traverse, just once, the "is instance of" relationship, from the receiver to its class. This allows the messaging system to get to the class of the object. Then, the messaging system looks into the correlation table hosted inside the class object in order to find the method that was invoked. If the method is not present in the table, the system follow the "inherits from" relationship, and try to find the method in the table of the super class. It goes upper in the hierarchy like this until it find the method or reach the root class.
  
  
  
  Since classes are themselves objects, one can send them messages. The process presented below is applied exactly in the same way. Since NSObject is the root class for not only the class hierarchy but also for the meta-class hierarchy, instances methods defined in NSObject can also be invoked on classes.
  
  
  
  Phil