This is a catchall to get more visibility into name choices:
File suffixes - current: ".sc", ".scj", ".schtml", ".sccss", ".sct"
Proposed: use 'stc' as the common prefix or maybe .scode or .strata
Should there be an explicit 'layer' and/or 'modify' keywords - or use 'override' as a class modifier? Currently both layer definition files and modify types just omit the 'class' but we could easily require a 'modify' there instead. For layers, maybe it's clearer if the word 'layer' is in the suffix for the file or in the definition file? I've avoided creating too many keywords because each one breaks all of the code which uses those keywords as identifiers.
replace codeType with codeComplexity or codeLevel?
replace codeFunction with codeRole. Possibly this should be multiple - "codeRoles" so each layer can set more than one - i.e. sometimes you mix, UI, Database, etc. Add Database as a codeRole.
You should be able to set more than one for a given layer or type cause code is not always split by layer or type according to these filters
Also settable as an annotation on a type or property that is inherited up the chain - so this organization is tunable on a per property basis via annotations
Change to "super"
Right now, super refers to modified type when you are inside of a method which is modifying a method in a base type. The thinking is that it makes no sense to be able to access both the base class's method and the modified method independently as everything should go through the base class's method if it's there. That seems to hold up but when you are in a method which is not modifying a base-type's method, do you want access to both the super-classes method and the modified-types's version of the method? We used to implement it that way and changed it recently. A third option is to add a new 'modify' operator and make it totally explicit. The same keyword could be used for the classe level modify and the super expression-like modify I bet without messing up the syntax.
Replace 'object' keyword with 'singleton'? Another word for the same thing.
Layer Definition Files:
Should layer definition files be simpler? Does requiring them to use the layer group name help provide structure or just an annoying thing you hav
e to keep up to date as you move files around. Maybe they could just be like:
layer {
}
Maybe the name should be "layer.lc" as well? How would that affect error messages and getting the right thing reliably?
What about override? Maybe override, modify, layer are all the same new operator just applied to a layer def file, a type, or a property or method
.
If you specify the name of a layer group in a layer extends, not the path to the layer, should it expand automatically to "main" if there's one? This will let you split any layer
into multiple since a.b will be equivalent to a.b.main.
Hierarchical layers: Essentially, when there's a layer def file inside of the parent layer, it's excluded from the parent's src files. The parent
can extend the children or vice versa, they are just different layers that happen to live one inside the other. This also gives you flexibility with splitting layers and refactoring without having to change published names. On the downside, layers are already hard enough to understand.
Another option is to define a process of splitting a layer. Instead of having one layer inside of the other, there's a 'main' layer which is used if you refer to a layer which is a group of layers. If main is not defined, it's an error to refer to the group. You could always split one layer into multiple and move the old layer into 'main', then define a bunch of new layers. The new 'main' could extend or be extended by any other sub-layers as needed.
This is a catchall to get more visibility into name choices:
File suffixes - current: ".sc", ".scj", ".schtml", ".sccss", ".sct" Proposed: use 'stc' as the common prefix or maybe .scode or .strata
Should there be an explicit 'layer' and/or 'modify' keywords - or use 'override' as a class modifier? Currently both layer definition files and modify types just omit the 'class' but we could easily require a 'modify' there instead. For layers, maybe it's clearer if the word 'layer' is in the suffix for the file or in the definition file? I've avoided creating too many keywords because each one breaks all of the code which uses those keywords as identifiers.
Change to "super"
Replace 'object' keyword with 'singleton'? Another word for the same thing.
Layer Definition Files:
Should layer definition files be simpler? Does requiring them to use the layer group name help provide structure or just an annoying thing you hav e to keep up to date as you move files around. Maybe they could just be like:
layer { }
Maybe the name should be "layer.lc" as well? How would that affect error messages and getting the right thing reliably? What about override? Maybe override, modify, layer are all the same new operator just applied to a layer def file, a type, or a property or method .
If you specify the name of a layer group in a layer extends, not the path to the layer, should it expand automatically to "main" if there's one? This will let you split any layer into multiple since a.b will be equivalent to a.b.main.
Hierarchical layers: Essentially, when there's a layer def file inside of the parent layer, it's excluded from the parent's src files. The parent can extend the children or vice versa, they are just different layers that happen to live one inside the other. This also gives you flexibility with splitting layers and refactoring without having to change published names. On the downside, layers are already hard enough to understand.
Another option is to define a process of splitting a layer. Instead of having one layer inside of the other, there's a 'main' layer which is used if you refer to a layer which is a group of layers. If main is not defined, it's an error to refer to the group. You could always split one layer into multiple and move the old layer into 'main', then define a bunch of new layers. The new 'main' could extend or be extended by any other sub-layers as needed.