Core BTypes and some other definitions.
Core BTypes and some other definitions. The initialization of these definitions requires access to symbols / types (global).
The symbols used to initialize the ClassBTypes may change from one compiler run to the next. To make sure the definitions are consistent with the symbols in the current run, the intializeCoreBTypes method in BTypesFromSymbols creates a new instance of CoreBTypes in each compiler run.
The class BTypesFromSymbols does not directly reference CoreBTypes, but CoreBTypesProxy. The reason is that having a var bTypes: CoreBTypes would not allow import bTypes._. Instead, the proxy class holds a CoreBTypes in a variable field and forwards to this instance.
The definitions in CoreBTypes need to be lazy vals to break an initialization cycle. When creating a new instance to assign to the proxy, the classBTypeFromSymbol invoked in the constructor will actually go through the proxy. The lazy vals make sure the instance is assigned in the proxy before the fields are initialized.
Note: if we did not re-create the core BTypes on each compiler run, BType.classBTypeFromInternalNameMap could not be a perRunCache anymore: the classes defined here need to be in that map, they are added when the ClassBTypes are created. The per run cache removes them, so they would be missing in the second run.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4