Refactor programming terminology

[alerque]

We have:

• [x] base classes
• [x] base shapers
• [ ] prototype frames
• [ ] node factories
• [x] default typesetters
• [ ] und languages
• [x] common inputs → base inputters
• [x] dummy outputs → base outputters
• [x] packages → base packages
• [ ] liang hyphenators¹

All of these thing "names" identify essentially the same thing. I'm tired of the chaos and hereby propose we pick some coding nomenclature defaults and stick to them. This should be relatively easy to shim if we pick a standard, and it would make writing new code a lot easier if you learned once what naming SILE used and then it applied to all the different parts.

As a follow up the "global" namespace SILE. is completely scrambled with state, packages, functions, prototypes, and all sorts of stuff just stashed around. Cleaning up the above naming would make it a lot easier to cleanup the namespace.

Somewhat related, we have some top level namespace stuff in camelCase, some InitCaps, and some lowercase. Some of these trace back to histories in external projects, but some is just us.

---

We also have

• [ ] register commands (Lua)
• [ ] define commands (declarative markup)
• [ ] create command ← not a typo, createCommand() is unrelated to registerCommands()
• [ ] declare settings
• [ ] declare frames ← unlike other declares, this is actually an instantiator
• [ ] register units
• [ ] register hooks
• [ ] add symbol
• [ ] add constraint

I'm not saying these all have to be unified, some subtle distinctions do exist — but I just had to look up whether it was registerUnit() or declareUnit() and given the context that I had declareSettings() and registerCommands() in the same scope and just didn't know which convention to follow using consistent naming would have made this obvious.

¹ _{Ironically this is the one where the name makes the most sense.}

[alerque]

We also have

• register commands
• create command ← not a typo, createCommand() is unrelated to registerCommands()
• declare settings
• declare frames ← unlike other declares, this is actually an instantiator
• register units
• register hooks
• add symbol
• add constraint

I'm not saying these all have to be unified, some subtle distinctions do exist — but I just had to look up whether it was registerUnit() or declareUnit() and given the context that I had declareSettings() and registerCommands() in the same scope and just didn't know which convention to follow using consistent naming would have made this obvious.

[alerque]

I'm retargeting this issue because not all of these are taken care of, but a lot of progress went has been made for v0.14.0. We now have base packages, classes, inputters, outputters, and shappers. We still need frames, languages, and typesetters but I'm putting off the related breaking changes for another release cycle.

[Omikhleia]

None of this is Needed.

[Omikhleia]

None of this is Needed.

One has to admit being wrong sometimes :) Having worked on #1768, nodefactory sounds really bad, since all objects in it are now classes.

[alerque]

It's easy to get blinded to things the way they have been or the way you learned them. I did (and presumably still am) the same. Every once in a while I get broadsided by how inconsistent/illogical some SILE terminology is. I still think we should push to clean it up for the long term health of the project even if there is some short term pain.

The good news is pure renames are easy to deprecate with shims for transition periods.

[Omikhleia]

und languages

What's the problem with this one? "und" is ICU-defined IIRC.

[alerque]

Probably nothing is wrong with und as a language code. I found it in a few places that were not language codes though, and somehow we have to figure how how to handle a base class (does und map to just a base language class instance with no other properties?), the unicode spec (or is this the base for everything), the "liang" rules used in most of the languages etc.

Just because I mentioned terms here doesn't mean they have to go, I was just pointing out the inconsistencies in usage and looking for which ones made sense and which don't.