blob: 99b356df0f3066420bc8f2455ca9b2b68ba31d7c (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
|
Can the sources.index file be removed?
======================================
Problems with `sources.index` files:
* Scalability. But this could be solved by per-directory index files.
See also `large_classes.txt`
* Usability. It adds slightly to the learning curve. And it's an
annoying additional step when adding a new class/file.
Possibly avoidable issues:
* Utility files: Are they really necessary?
* Reduced paralellism: Can list `*.slul` and speculatively parse them
(in the beginning, when not all cores are in use). Need to pause on
error (and defer any warnings), since there could be files that aren't
actually referenced.
* Local classes/files vs imported classes. Could be solved by explicit
imports of classes (maybe even of local classes, like Java?)
Trickier issues:
* Class extensions. All imported classes can be extended, meaning that
those have to be searched for as well. That would be less efficient
(if doing an `open` for each file), but it could be solved by instead
listing `*.slul` first and building a hashmap (or even speculative/
parallel parsing)
* How to specify that a class has entry points / is a service?
- Maybe this information could go inside the file?
- Require services to end with `*Entry.slul` ?
(Or perhaps a service-dependent ending?)
- Require an extension class for the service interface that is
being implemented, and somehow reference the classes from there?
|
