[prev in list] [next in list] [prev in thread] [next in thread] 

List:       bsdinstaller-discussion
Subject:    Planned changes to main (development) branch
From:       "Chris Pressey" <cpressey () gmail ! com>
Date:       2006-09-01 20:19:30
Message-ID: f32433650609011319i7d01b212m361032afb1b8bbb8 () mail ! gmail ! com
[Download RAW message or body]

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.

-Chris

[prev in list] [next in list] [prev in thread] [next in thread]