|
|
Esteban A. Maringolo wrote:
> What is the strategy used in the loading of a package in which some
> classes or methods depends on the others, and the chunk that defines
> them appears before the dependent?
I believe that the order of loading is:
1) Load and initialise any pre-requisite packages.
2) Execute the pre-install script.
3) Add preliminary definitions of any globals in the package (all nil).
4) Define all the classes in the package.
5) Populate any PoolConstantsDictionaries (and PoolDictionaries).
6) Compile their methods. (This is why we need the globals and constants
already defined)
7a) Set the other globals to their correct values.
7b) Define resources. (Presumably not necessary for D6 packages, I haven't
checked)
8) Send #initialiseAfterLoad to all the classes (which will call the
classes' #initialize methods if they are defined)
9) Send #initialiseAfterLoad to the values of any globals that understand it.
10) Run the post-install script.
(I've probably missed one or two steps)
Within each step the order is not defined, and should not be relied on. That
can cause problems in three cases that I know of.
A) In step (6) if you have used any compile-time expressions which rely on
either other methods being defined, or on any class or global being correctly
initialised, then it may break.
Solution: Don't use compile-time expressions with such dependencies.
B) In step (7) we de-STB various objects. If they are instances of any of the
classes in the package (e.g. D5 View Resources) then any custom de-STB code
will run before their classes are initialised.
Solution: I don't know of one. I've never known it cause problems, though.
C) In steps 7 and 8, initialisation of one class (or object) may depend on
another class (or object) being already initialised.
Solution 1: Arrange that they initialise themselves automatically when they are
used if they have not been initialised already (taking care to avoid loops).
Solution 2: Only do local initialisation at this stage, and postpone global
initialisation for a second step which is invoked from your post-install
script.
-- chris
|
Locked
