Wiki 結構

wiki

這個頁面的標題「LuaAddons」，我覺得不是最能描述的標題。[根據維基百科說明]，一個「附加元件」較像外掛程式，對於 Lua 這種語言而言，這會是一個模組，模組在另一個頁面 (LibrariesAndBindings) 中列出。這個特定頁面似乎較著重於可被用於 Lua 開發的工具。你可能特別會將這其中許多稱作[電腦輔助軟體工程工具]，主要例外的是「Lua distribution」和「documentation」區段。說明文件顯然不是附加元件，distribution 也可能不是。請注意，LuaPowerPatches 與 distribution 部分相關 (例如 Lua 自身的 patched/modified/custom 版本)，因此這些頁面中有些部分可以進行分組。 --DavidManura

[LuaAddons] 是為了編制「給 Lua 使用者的事物」索引，包括程式庫、說明文件、開發工具及 distribution。或許「Lua addons」不是最好的用語，但這個頁面的第一句話中已釐清 intended meaning，而且這樣比「給 Lua 使用者的事物」容易表達。 --JohnBelmonte

想想這三個界線模糊的部分：本 wiki 的內容 (LuaDirectory)、關於 Lua 自身的外部連結 (LuaLinks)，以及給 Lua 使用者的所有其他事物的外部連結 (LuaAddons)。我想，在介紹這個頁面的第三段中已經說明得很清楚了。 --JohnBelmonte

我一直覺得，在組織方面，內部連結與外部連結之間的區分是人為的。有些東西甚至同時存在於內部和外部 (例如 MetaLua v.s. [Metalua])。例如，我最近剛將語言比較區段從 LuaLinks 移到 LuaComparison。 --DavidManura

在 HomePage 上，焦點頁面與起點在哪些方面不同？例如，為什麼 LuaDirectory 不是焦點頁面？ --DavidManura

起點提供 wiki 的主要索引頁面，以及提供回饋意見的地方。這些起點依定義都是一般性的，永遠不會變成焦點頁面。 --JohnBelmonte

我傾向覺得 LuaDirectory 的內容在主頁上，以某種方式來說，會比當成從屬連結更實用。目前的結構感覺有點顛倒而令人迷失方向。 --DavidManura

頁面名稱如果只有一個單字，通常會加上適當的「Lua」，且只有縮寫字的第一個字母會大寫 (例如 LuaFaq，而不是 Faq 或 LuaFAQ)。有例外，例如 LuaPowerPatches 和 IoLanguage。

users.lua.org 可能比 lua-users.org 更合理，儘管此處已討論過：https://lua-users.dev.org.tw/lists/lua-l/2001-07/msg00208.html。

LibrariesAndBindings 與 LuaForge 的目的有些重疊。LuaForge 較大（包含 215 個專案），不過並非註冊在裡面的專案都是模組。但並非所有 Lua 專案都註冊在 LuaForge。有些專案是混合模式：註冊在 LuaForge，但檔案儲存在其他地方。有些模組僅在 SampleCode 區段的 wiki 中非正式維護。有些模組已註冊在 LuaRocks 資料庫中。沒有像 CPAN 那樣的中央位置，可供註冊模組。

建議的 Lua Wiki 指引

以下是針對此 wiki 的建議或我認為的良好規範。--DavidManura

(1) 所有程式碼或頁面都應標示預計執行的 Lua 版本。

一個範例

-- Compatible with Lua 5.1 (not 5.0).
function test(t)
  print(t, # t)
end

過去曾遇到的問題是，人們將 Lua 4 範例新增到 wiki 中。然後 Lua 5.0 和 5.1 陸續推出，而這兩個版本通常無法辨識 Lua 4（甚至有時無法辨識 Lua 5.0）。但 Lua 4 的程式碼仍保留在 wiki 中，而讀者卻渾然不知。Asko 同意 [1]。標示版本可大幅解決此問題。事實上，此措施已強制套用於 LuaPowerPatches。此外，如果您找到舊程式碼，但目前沒有時間進行調整，建議使用 VersionNotice 進行標示。

理想狀況下，我們希望 wiki 中的舊 Lua 程式碼轉換成 Lua 最新版本。儘管如此，我認為將舊版本保留為歷史參考註釋還可以，甚至是可取的。只要將其標示出來即可。

(2) 正確的互動式 Lua 資訊重點標示會很有用，因為這在 wiki 中經常發生。您可以使用常规的「Lua」語法重點標示，這通常都可以正常運作，但並不總是如此

> = "test if [["
test if [[
> = "test]]"
test]]

wiki 使用的 Perl 程式碼其中一個版本位於 LuaToHtml。我想提供一個修補程式，但請參閱那裡的留言。

(3) C 語法重點標示。

這有助於許多 C 程式碼範例。也已由 RiciLake 在 GuestBook 中提出要求。

(4) 編寫頁面的風格建議

基於編輯大量頁面，以下是筆者認為對於作者和編輯都有用的良好做法。使用 Lua 語法重點顯示功能。將程式範例右縮排（如上方 Lua 範例所示），以將其與周圍文字區隔開。避免使用 tab 縮排，而是使用兩個（或三個）空格，這點遵循 Lua 手冊和 PiL 書籍風格，筆者也認為這最適合 wiki 這種媒介。在表達式中避免使用額外的空格，例如 x = f( x, y ) or { a , b } 而應使用 x = f(x, y) or {a, b}--一般來說，請使用與 wiki 上其他頁面一致的慣用風格。說真的，我剛找到這個：SourceCodeFormatter。

有些頁面在性質上非常相似，因此會分為某些分類，這樣就能套用一些一致性。其中一個範例是SampleCode。

(5) wiki 的結構

一些先前對於整體 wiki 結構的評論位於 WikiStructure，但筆者仍在對整體結構形成意見，目前為止，較高的優先級是審閱 wiki 大部分內容，如下所說明。

(6) 定期審閱內容。

應定期審閱 wiki 上的內容，以確保品質、一致性，以及內容的正確性。隨著 Lua 變更，以及 Lua 社群改變，已發表的內容隨著時間推移會變得不怎麼正確（如上方的 Lua 4 案例所示）。我目前正在審閱 wiki 大部分內容。

要刪除的頁面

這些頁面可以刪除。

要移動的頁面

這些頁面可以移動。

• 將 LexicalAnalysis 改名為 LuaLexerInReToCee? （建議重新導向）。前面的標題過於籠統。它提供一個使用 re2c 工具的特定詞法分析器，因此僅為 LuaGrammar 中許多可用的 Lua 詞法分析器之一。連結出現在 LuaList? 中不過。

• IndexIntervalFormatIssue 可以有更好的名稱。這與 CountingFromOne 的關聯性非常密切，而它們可以使用區段合併成一個較長的單一頁面會更好。 IndexIntervalFormatIssue 是有些重點的邏輯摘要，不過可能無法全面摘要 CountingFromOne 中表達的所有重點。

其他

• LuaUnit 頁面應移除或從 UnitTesting 萃取 luaunit 區段加以填補。--DmitryGaivoronsky

• LuaBinaries：是否有任何理由讓 LuaBinaries 維持目前狀態？我看到兩條改善方法

1) 可以清理/更新。大多數連結只會指向 LuaAddonsArchive。

2）它可以簡單地被放棄／移除。所有實用的內容（即 BEOS 和 Linux ARM/SH3 連結）將會整合到 LuaDistributions 中

我投票支持第二項。 --Dmitry Gaivoronsky

• WikiFormattingExamples：不喜歡 Lua 本身，它很簡約，但對使用者來說並不簡單。（部分簡約範例可以在 TutorialDirectory 中找到） --Dmitry Gaivoronsky

Lua目錄和分類

在我個人用戶頁面中查看新的 LuaDirectory 結構提案：< a href="/wiki/DmitryGaivoronsky">Dmitry Gaivoronsky. 注意：

某些意見和章節標題聽起來可能很奇怪（我的英文不好，請見諒），需要修正。

有些意見遺漏了。

有些章節尚未經過仔細思考，需要進一步整理；有些頁面可能分類錯誤。

我已制定一項政策（並發現這很方便）—將連結至包含目錄的全部頁面的連結加上斜體，例如連結清單或提交表單。但這可能會收到批評。

在 wiki 引擎沒有原生支援分類的情況下，要建立並維護一致的 wiki 結構可能非常困難。 --Dmitry Gaivoronsky

我認為 LuaProgramming 和 LuaCoding 這兩個術語本質就是同義的（例如編寫出原始程式碼）。LuaProgramming 頁面上的連結處理結構和模式在 Lua 原始程式碼中的應用和表示方式。 LuaCoding 頁面上的連結似乎較偏重於與 Lua 程式碼使用與開發相關的流程，主要提到了軟體工程[2] 方面的內容，這些內容可能甚至不包含在 Lua 語言本身中。因此我暫時建議頁面名稱為 LuaProgramming 和 LuaEngineering?。 --David Manura

與先前的重組類似，我無法表示贊同。專案在各頁面之間變得過於支離破碎，階層越來越深，交互參照不斷增加。這突顯了 wiki 的弱點，特別是這個簡單的 wiki 執行。的確，單頁式頁面不完美，但它們有優點：減少混淆的地方，降低到處新增導覽說明的渴望，讓較寬廣的畫面一目了然，減少重複說明目錄指引或政策的機會（或省略說明並應付後果）。對於限制的要求（例如將階層限制為 2 層），有些論點可以支持。**我不認同將斜體字用於索引頁面參照—這有點過度使用格式，但獲益不多。我是否真的會決定要點選連結而取決於連結是不是索引？ --John Belmonte

我同意所提議的重整，不過有一些 John 提出的疑慮。儘管 LuaLanguage、LuaProgramming 與 LuaCoding（又或稱 LuaEngineering?）組成一個自然進程（定義語言、使用語言與組織語言使用），但 LuaDomains 可能與其他頁面高度相關。

我也認為，也許通常來說，使用者不會想要前往的索引頁面不應存在。我認為，典型的使用者會到 wiki 詢問例如「如何在 Lua 中定義物件？」（解決方式：ObjectOrientedProgramming）、「如何將物件序列化？」（解決方式：TableSerialization）、「我應該如何建構模組？」（解決方式：ModuleDefinition）、「我如何進行平行程式設計？」（解決方式：MultiTasking）、「我如何將非 Lua 程式碼繫結至 Lua？」（解決方式：BindingCodeToLua）、「在哪裡可以為我的平台找到『附帶大量內建功能』的 Lua 建置？」（解決方式：LuaDistributions）等問題。正如所見，可能有一個頁面在這個主題上相當全面且一致。現在對於 LuaLanguage，問題是「我正在尋找比參考手冊更詳細的 Lua 語言說明。另外請出示『增強提案與第三方修改』下的各種其他隨機資訊。」對於 LuaProgramming，問題是「我如何建構程式碼以達成特定目標或提升品質？」對於 LuaCoding，問題是「出於 Lua 語言本身以外，我可以使用什麼工具和方法來達成特定目標或提升品質（與 LuaAddons 有點不同）？」對於 LuaDomains，問題是「請提供一個以主題分類的清單。」在四個頁面中，我認為 LuaProgramming（曾經稱為「Lua Fu」）最為一致，而且我曾考慮自己提取這類頁面。事實上，它在目的上與 Lua Programming Gems 程式集有些類似。如果有人想要的話，我認為 LuaLanguage、LuaProgramming 和 LuaCoding 頁面可以合併為單一頁面，儘管可能仍維持相同的分組。這個合併後的頁面將說明如何有效達成目標。儘管如此，也許那頁面就是 LuaDirectory。--DavidManura

JohnBelmonte，但 wiki 技術並不是專為少數地方設計，而是更加適合各地。為了避免迷失（讀者在搜尋/瀏覽時不致迷失，編輯者在建立/維護結構時亦不致迷失），大家發明了分類。坦白說，這一切主要是為了模仿 MediaWiki 的分類[3]... 您用過嗎？）。為了避免重複，大家發明了範本。（您用過嗎？）我認為嘗試讓 wiki 結構適應 wiki 引擎的作法並不好。我們應該考慮讓 wiki 引擎適應 wiki 結構。

斜體字的原因。Wiki 技術建議出於瀏覽和可見性的目的，每一頁應至少在一種分類/目錄/索引中列出。斜體字的想法來自於標示視為此類分類的必要性。

階層中的交叉參照並非弱點。事實上，它是分類一致性的基本功能。分類的層級結構無法表示為一棵樹；它是一個沒有迴圈的有向圖形[4]。

限制單一頁面的層級深度至 N 層是一個合理的方法。並非為了迫使它在單一頁面中變淺，而是將深層分支萃取至單獨的頁面。（我建議最大深度為 4，例如將 5 層分支切割成 3 層和 2 層。）跨頁面層級的深度不應該受到限制。

DavidManura，「工程」~=「軟體工程」。對我而言，LuaEngineering? 讓人聯想到 CAD/CAE 系統（...在某處的 LuaDomains）。--DmitryGaivoronsky

是的，我在 10 多年前就在一個 wiki 上使用過 wiki 分類。您甚至可以在像這樣的簡單 wiki 上執行這項操作，方法是讓幾個頁面參照分類頁面，並使用後向參考功能。但是當我在 2001 年啟動 lua-users wiki 時，我特別注意不要引入此類複雜性，並避免在我過去經驗中在 wiki 上遇到的許多類似的混淆陷阱。當時，我非常熟悉具備許多功能的 wiki 引擎，以及後續的幾年。即使從這個簡單的引擎開始，我也花了一點時間找出一些功能，讓事情能保持簡單。組織和分類事務的任務可以被做得過度，並且會失去內容（真實的價值）的重要性。您自年初以來進行的重組，已違背了我對網站的既定意向，但我不想當獨裁者。我重視 David 的意見，因為他多年來一直非常注意這個 wiki 中的内容和組織，所以我請您考慮他的建議和回饋。** 我想您誤解了我對限制層級的意思。我指的是分頁式層級，而非頁面內的標題層級。換句話說，我想要更少的頁面，而不是更多。 --JohnBelmonte

（軟體）工程/建構確實可能只是一個微小的進步。此 wiki 在某種程度上支援分類（例如 ObjectOrientedProgramming）。點選頁面標題以提供連結至該頁面的已按字母順序排列頁面清單（反向連結）的功能相當低階，且大部分使用者可能不明白。而且，「A 連結至 B」比「A 是 B 的子/超類別」更為一般化的關係。然而，此功能對 wiki 作者來說相當有用，可藉此檢查頁面是否已正確交叉連結及加入母頁面（如果沒有，則手動修正）。--DavidManura

LuaDocumentation（LuaAddons 的一部分）和 LuaLanguage 的目的部分重疊。此外，考量到 John 最上方對「關於 Lua 本身的外部連結（LuaLinks），以及關於 Lua 使用者所有其他事項的外部連結（LuaAddons）」的說明，以及我的特徵描述「LuaLanguage、LuaProgramming 和 LuaCoding（又稱為 LuaEngineering?）形成一項自然進程（定義語言、使用語言，以及組織語言的使用方式）」時，人們至少會在某種程度上將 LuaLinks 與 LuaLanguage/LuaDocumentation 類比，就像將 LuaAddons 與 LuaCoding 類比一樣。我認為 LuaAddons（包括 LuaDocumentation、LuaTools、LibrariesAndBindings，...）傾向於與具體的事物（檔案/函式庫/外掛程式/工具程式）打交道，而 LuaLanguage 和 LuaCoding 則傾向於與主題、問題、說明和思考過程打交道。 LuaDomains 可能兼具兩者。DavidManura

我認為 LuaPowerPatches 應作為 LuaAddons 中的頂層連結，而不是那麼多在首頁上（儘管「修補程式」仍會列在 LuaAddons 連結的說明中）。修補程式與發行版、實作、編輯器外掛程式、函式庫和工具屬於同一個層級。--DavidManura

LuaPowerPatches 是此 wiki 中影響 Lua 社群最顯著的頁面。很抱歉看到它被移除為首頁上的精選連結。--JohnBelmonte

我對此也有些遲疑。LuaPowerPatches 可以是一項推薦項目，儘管它已包含在 LuaAddons 中。其他一些 LuaAddons，例如 LibrariesAndBindings、LuaDistributions 及 LuaImplementations 也相當重要。不過，與其他語言相比，補丁在 Lua 中具有某種特殊的意義，因此我了解希望讓它突出的渴望。對於目前在首頁中呈現補丁的方式，我並未完全設下限制。我認為 LearningLua 及 LuaComparison 也足夠重要可以被推薦，儘管它們已在 LuaFaq 中凸顯。——DavidManura

我目前並未對 DmitryGaivoronsky 中的 LuaDirectory 頁面切割有強烈的意見。不過，如果進一步減少它（例如將社群區段移至新的 LuaCommunity? 頁面），那麼 LuaDirectory 可能可以合併至 HomePage，這與我在 WikiStructure 頂端區段中的想法相符。——DavidManura

我比較希望首頁能維持我最初撰寫的樣式——簡潔且連結少於 10 個。——JohnBelmonte

DmitryGaivoronsky 中建議的目錄結構中，將非常廣泛的觀點（例如，LuaLanguage、LuaAddons、LuaDomains，...）與較具體的連結（例如 GoogleSummerOfCodeIdeas）相混淆。我建議擇一使用。以下是僅採用廣泛連結（約 10 個連結）可能呈現的樣式。——DavidManura

• 指示
  • LuaIntroduction? - 簡介、常見問答集、語言比較、書籍、教學課程
  • LuaLanguage - 語言定義、操作說明、功能建議與文章
  • LuaProgramming - 一般演算法、技術、模式與典範
  • LuaDomains - 特定領域的方法、技術與模組
  • LuaCoding - 程式碼建立、建立、連結、測試、最佳化、維護及分享
• 事項
  • LuaAddons - 協力廠商補丁 (LuaPowerPatches)、SampleCode、分發、函式庫及 Lua 的工具程式
• 人員與活動
  • LuaCommunity? - 討論小組、聚會、用途、徵求、新聞
  • CastOfCharacters - 重要人物
• 此網站
  • WikiHelp - 如何使用此 wiki
  • GuestBook - 關於此網站的意見回饋

依邏輯來說，「引言」應屬於Lua語言。我將「引言」與「社群」保留在最上層，主要是為了方便以及填補空間。這些子主題可能太小，不值得另闢新頁；但如果你覺得這樣更一致，我也無所謂。然而，我相信我們應該避免在註解中加入連結——它們幾乎不會被直接使用，而會在清單中造成更多混亂。——Dmitry Gaivoronsky

這說得有道理。以下是重新整理的結果。最上層清單會是主要分類區塊。第二層清單會是那些區塊中的重點重點頁面（如有）。我不確定是否需要將Lua 程式設計和Lua 範疇分開（請參閱上面關於Lua 範疇的先前註解）。——David Manura

• LuaLanguage - 語言定義、操作說明、功能建議與文章
  • 學習 Lua - Lua 入門（一個引導目錄）
  • Lua 教學 - 由 Lua 使用者撰寫與審閱的教學資訊
  • Lua 常見問答集 - 非官方、由社群維護的常見問答集
  • Lua 比較 - Lua 與其他語言的比較
  • Lua 書籍 - 有關 Lua 主題的書籍清單
  • Lua 連結 - 一份手動編輯的、有用的 Lua 連結清單
• LuaProgramming - 一般演算法、技術、模式與典範
• LuaCoding - 程式碼建立、建立、連結、測試、最佳化、維護及分享
  • 建立 Lua - 編譯 Lua 和一些建置套件的注意事項
  • 將程式碼連結到 Lua - 如何呼叫或將 C 或 C++ 程式碼連結到 Lua
• LuaDomains - 特定領域的方法、技術與模組
• Lua 外掛程式 - Lua 的修正程式、範例程式碼、發行版本、函式庫和工具
  • 範例程式碼 - Wiki 中所有包含有用程式碼的頁面（Lua、C、C++）
  • Lua Power Patch - 第三方修正程式
  • Lua 實作 - Lua 的替代實作
  • Lua 發行版本 - Lua 發行版本（Lua + 特定平台的函式庫）
  • 函式庫和連結 - Lua 函式庫或具有 Lua 連結的函式庫
• LuaCommunity? - 討論小組、聚會、用途、徵求、新聞
  • CastOfCharacters - 重要人物
  • Lua 新聞 - 郵件清單中最新訊息的摘要
• WikiHelp - 如何使用此 wiki
  • GuestBook - 關於此網站的意見回饋

我建議不要挑選任何「重要」或「重點」頁面。這是一個非常主觀的事情。必須了解，如果 lua-users 變得更熱門，這將導致維基大戰（過濾 -> 還原 -> 審查制度）。畢竟，Lua 目錄「是這個維基的所有 Lua 內容的頂層目錄」，而重點頁面區塊位於首頁。

另一個選擇是只在第二層保留並收集標示為斜體的連結（即目錄）。這是一個正式的標準，很容易維護和執行。（但它可能過於正式而難以使用——這就是我在原始提案中允許一些例外的緣故。）

這點可能不清楚，但... 所有這一切都只是嘗試去發明一些已經發明過的事物。我仍在暗示類似於 Mediawiki 的分類（正如俄羅斯人所說，“為什麼我們要嘗試去發明一輛腳踏車？”）。 --DmitryGaivoronsky

The task of organizing and categorizing things can be overdone, and the importance of content-- the real value-- lost.

當大多數內容都被隱藏在地底下時，很難說明任何內容的重要性。這個 wiki 確實有很多網頁，但是其中許多幾乎沒有機會被一般使用者看到。（我發現一次用 wget 提取所有 lua 使用者內容比按照超連結閱讀來得更方便。）在雜亂無章的事物中（俄羅斯諺語：“在乾草堆中找針”）找到任何東西都非常困難。因此，我相信適當的問題是：引擎是否可擴充至如此多的網頁？（你能證明嗎？） --DmitryGaivoronsky

DavidManura，我們可以合併 LuaProgramming 中的**演算法**部分與 LuaDomains。這將會提供我們 LuaAlgorithms?。但... LuaDomains 中的並非全部都是真正的 Lua 演算法。（因此，在形式上，LuaDomains 和 LuaAlgorithms? 是平行的分類，而 LuaAlgorithms? 是 LuaProgramming 的子分類。） --DmitryGaivoronsky

請參閱

• http://c2.com/cgi/wiki?WikiMess