Merge "remove outdated design.txt."

diff --git a/docs/design.txt b/docs/design.txt
deleted file mode 100644 (file)
index 5c04add..0000000
--- a/docs/design.txt
+++ /dev/null
@@ -1,106 +0,0 @@
-design.txt
-
-This is a brief overview of the new design.
-
-More thorough and up-to-date information is available on the documentation
-wiki at https://www.mediawiki.org/
-
-Primary classes:
-
-  User
-    Encapsulates the state of the user viewing/using the site. Can be queried
-    for things like the user's settings, name, etc. Handles the details of
-    getting and saving to the "user" table of the database, and dealing with
-    sessions and cookies.
-
-  OutputPage
-    Encapsulates the entire HTML page that will be sent in response to any
-    server request. It is used by calling its functions to add text, headers,
-    etc., in any order, and then calling output() to send it all. It could be
-    easily changed to send incrementally if that becomes useful, but I prefer
-    the flexibility. This should also do the output encoding. The system
-    allocates a global one in $wgOut.
-
-  Title
-    Represents the title of an article, and does all the work of translating
-    among various forms such as plain text, URL, database key, etc. For
-    convenience, and for historical reasons, it also represents a few features
-    of articles that don't involve their text, such as access rights.
-    See also title.txt.
-
-  Article
-    Encapsulates access to the "page" table of the database. The object
-    represents a an article, and maintains state such as text (in Wikitext
-    format), flags, etc.
-
-  Revision
-    Encapsulates individual page revision data and access to the
-    revision/text/blobs storage system. Higher-level code should never touch
-    text storage directly; this class mediates it.
-
-  Skin
-    Encapsulates a "look and feel" for the wiki. All of the functions that
-    render HTML, and make choices about how to render it, are here, and are
-    called from various other places when needed (most notably,
-    OutputPage::addWikiText()). The StandardSkin object is a complete
-    implementation, and is meant to be subclassed with other skins that may
-    override some of its functions. The User object contains a reference to a
-    skin (according to that user's preference), and so rather than having a
-    global skin object we just rely on the global User and get the skin with
-    $wgUser->getSkin().
-    See also skin.txt.
-
-  Language
-    Represents the language used for incidental text, and also has some
-    character encoding functions and other locale stuff. The current user
-    interface language is instantiated as $wgLang, and the local content
-    language as $wgContLang; be sure to use the *correct* language object
-    depending upon the circumstances.
-    See also language.txt.
-
-  Parser
-    Class used to transform wikitext to html.
-
-  LinkCache
-    Keeps information on existence of articles. See linkcache.txt.
-
-Naming/coding conventions:
-
-  These are meant to be descriptive, not dictatorial; I won't presume to tell
-  you how to program, I'm just describing the methods I chose to use for myself.
-  If you do choose to follow these guidelines, it will probably be easier for
-  you to collaborate with others on the project, but if you want to contribute
-  without bothering, by all means do so (and don't be surprised if I reformat
-  your code).
-
-  - I have the code indented with tabs to save file size and so that users can
-    set their tab stops to any depth they like. I use 4-space tab stops, which
-    work well. I also use K&R brace matching style. I know that's a religious
-    issue for some, so if you want to use a style that puts opening braces on
-    the next line, that's OK too, but please don't use a style where closing
-    braces don't align with either the opening brace on its own line or the
-    statement that opened the block--that's confusing as hell.
-
-  - Certain functions and class members are marked with /* private */, rather
-    than being marked as such. This is a hold-over from PHP 4, which didn't
-    support proper visibilities. You should not access things marked in this
-    manner outside the class/inheritance line as this code is subjected to be
-    updated in a manner that enforces this at some time in the near future, and
-    things will break. New code should use the standard method of setting
-    visibilities as normal.
-
-  - Globals are particularly evil in PHP; it sets a lot of them automatically
-    from cookies, query strings, and such, leading to namespace conflicts; when
-    a variable name is used in a function, it is silently declared as a new
-    local masking the global, so you'll get weird error because you forgot the
-    global declaration; lack of static class member variables means you have to
-    use globals for them, etc. Evil, evil.
-
-    I think I've managed to pare down the number of globals we use to a scant
-    few dozen or so, and I've prefixed them all with "wg" so you can spot errors
-    better (odds are, if you see a "wg" variable being used in a function that
-    doesn't declare it global, that's probably an error).
-
-    Other conventions: Top-level functions are wfFuncname(), names of session
-    variables are wsName, cookies wcName, and form field values wpName ("p" for
-    "POST").