blob: 936c54d0dddc471c3d66f2d9bc220c1fc9910099 (
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
36
37
38
39
40
41
42
|
Large classes
=============
Some classes are large enough (like over 700 lines) that they might better
span over multiple files.
Ways to do this:
* Uppercase subdirectories, with the directory being the "class" and
lowercase files inside being merged into the class (and uppercase files
being nested classes).
- Should there be a main file?
- Or a nested `sources.index` file?
- Or should `Example.slul` be the main file, and `Example/*.slul`
be the additional contents? I.e. similar to `conf.d` directories.
* Double extensions, like `Output.expr.slul`
- In this case, maybe there should be some kind of "includes"
from the main file.
Tricky parts:
* How to find all files? (See above)
* Fields might be referenced before use
Related:
* Should there be a topmost class, which "utility files" extend?
- Advantages:
- Logical
- Makes it possible to have global state
- Disadvantages:
- Global state can be a disadvantage
- Global state won't be accesible from Uppercase/"nested" classes.
- Unclear when the state should be initialized. Initializing
everything at process startup is neither secure, safe or fast:
- It could do bad stuff if given I/O or system capabilities.
- But there's also no way to selectively limit capabilities.
- Initialization failure = crash?
- Slow initialization = slow process creation.
- Due to the disadvantages, I think it might be a bad idea.
|
