34 " |
34 " |
35 ! |
35 ! |
36 |
36 |
37 documentation |
37 documentation |
38 " |
38 " |
39 In memory limited systems (as my 8Mb 386 is) all seldom-used classes are made |
39 Autoload is a stub for an 'as yet unloaded' class. |
40 subclasses of this class. |
40 |
41 Autoload catches all messages and files-In the corresponding code |
41 In memory limited systems (as my original 8Mb 386 system was), |
42 when first used. |
42 all seldom-used classes were made subclasses of this class. |
43 Then the caught message is resent to the (now existing) class. |
43 Autoload catches all messages sent to it, and files-in the real class's |
44 |
44 code when first used. Then the caught message is resent to the (now existing) class. |
|
45 |
|
46 A note from later days: |
|
47 Theses days, systems usually have enough memory to allow |
|
48 having all classes present, so many of the classes which used to be |
|
49 autoloaded are no longer these days. However, a number of examples or |
|
50 very seldom used frameworks are still present as autoloaded. |
|
51 Instead of using autoloaded classes, it is now recommended to bundle |
|
52 extra classes into packages, which are loaded en-bloque. |
|
53 Packages can be compiled to a shared class library and thus be loaded |
|
54 much faster (there is no need to parse and compile source files). |
|
55 |
|
56 Lazy loading: |
45 Class files are searched along the searchPath (see Smalltalk), |
57 Class files are searched along the searchPath (see Smalltalk), |
46 and any of binary-classFile, byteCode-classFile or sourceFile are |
58 and any of binary-classFile, byteCode-classFile or sourceFile are loaded, |
47 loaded, whichever is found first. For binaries to be loaded, |
59 whichever is found first. |
48 these must be found in the 'bin' directory. Sources must be found |
60 For binaries to be loaded, these must be found in a package-subdirectory |
49 in the 'source' directory. |
61 along the so called package path. |
50 (Usually, Autoload classes finds the source file and loads that one). |
62 Sources in a package directory along the source path. |
51 |
63 In practice, most Autoloaded classes are found and loaded as source file. |
52 When started, the patches startup script arranges for the abbreviation |
64 |
53 file 'include/abbrev.stc' to be read and installs autoload stubs for |
65 Initial Setup of Auoload Stubs: |
54 all classes listed in that file, which do not exist already. |
66 At initial startup (i.e. when ST/X is NOT coming up with an image), |
55 The abbreviation file is maintained by the production environment |
67 the 'patches' startup script recursively walks along all directories |
56 and updated by makefile rules - therefore, it should not be edited |
68 below the TOP directory (that is one above the stx folder), |
57 manually. |
69 and installs autoload stubs for all .st class files found, for which no |
58 |
70 corresponding class is already present. |
59 Late addition: above comment is no longer true - I have made now almost |
71 As you can imagine, this takes a long time and makes the initial startup quite slow. |
60 all Demos & Goodies be autoloaded ... even for big systems. |
72 Therefore, this scheme is no longer the recommended one and we (at exept) |
|
73 always start ST/X with the '--quick' option, which skips this scan operation. |
|
74 |
|
75 Advantage of Autoload stubs: |
|
76 Autoload stubs make it easier for a beginner to ST/X, to see what frameworks and classes |
|
77 are there, as they appear in the browser with category and class name (although no |
|
78 more details are initially visible. |
61 |
79 |
62 [class variables:] |
80 [class variables:] |
63 |
81 |
64 LazyLoading <Boolean> if true, the loaded classes |
82 LazyLoading <Boolean> if true, the loaded classes |
65 methods will NOT be compiled at |
83 methods will NOT be compiled at |