Package installation class/methods order

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Package installation class/methods order

Esteban A. Maringolo-3
Hi,

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?

Regards,

--
Esteban.


Reply | Threaded
Open this post in threaded view
|

Re: Package installation class/methods order

Chris Uppal-3
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