Chris Pressey wrote a detailed list of the changes he is planning for the next version of the BSD Installer. It was on the BSD Installer mailing list, which has no web archives that I know of, so the body of the message is pasted here:
“This is a bit of a “heads up”. Since we’ve established a production branch, I’ve been accumulating sweeping architectural changes to make to the development branch. Since they’re kind of disruptive, I’d like to do them all at once to minimize the pain. If you have patches to the files affected (basically everything in backend/lua/lib,) it would probably be better to apply them to the production branch for now.
I’m sorry if I appear to be emphasizing architecture over features lately, but I do believe that getting the architecture right will let us add new features without resorting to hacks.
Four major changes are:
1. Seperate classes into their own module files. Instead of e.g. a class called Storage.Disk, just have a class called Disk, and have it in its own module in its own file. Name the module and the file the same as the class in it, i.e. “Disk.lua” This will involve several repocopies.
2. Move from closure-based objects (PiL ?.??) to prototype-based objects (PiL ?.??). They’re easier to subclass, easier to test and debug, and generally more “standard” in the Lua culture. The drawback is that they don’t enforce privacy.
3. Make subclassing work in the prototype-based way. This is particularly relevant to where we’re already using subclassing (UINav) and where it will become more important (Disk and friends.)
4. Rename the following classes to better reflect what they are or do:
TargetSystem -> Installation
TargetSystemUI -> InstallationUI
This class applies to the source system as well as the target, so “target” is really a misnomer. It could be said that the raison d’etre of the BSD Installer is to copy one Installation (the LiveCD) to another (your HDD.)
ConfigVars -> ConfigFile
This really is an abstraction of a configuration file; the fact that it contains variables is important, but something of an artefact of the configuration files we’re used to dealing with. It’s easier to think of it as a file.
UINav -> NavContainer
UINav.Atom -> NavLeaf
Navigation implies user interface – plus there’s nothing really about UI (as we’re using the term elsewhere) in the UINav classes. Also, “leaf” is a somewhat more descriptive term than “atom” when the context is trees, although I suppose that’s debatable.”