维基结构
lua-users home
wiki

对当前维基结构/组织的描述或讨论。 这是描述性的，而不是规定性的。

我认为此页面的标题“LuaAddons”不是最具描述性的。 [根据维基百科]，“附加组件”更像是插件，对于像 Lua 这样的语言来说，它就是一个模块，在单独的页面 (LibrariesAndBindings) 中列出。 此特定页面的重点似乎更多地是可用于 Lua 开发的工具。 你可能会专门称许多这些工具为 [CASE 工具]，主要区别在于“Lua 发行版”和“文档”部分。 文档显然不是附加组件，发行版也可能不是。 请注意，LuaPowerPatches 部分与发行版相关（即 Lua 本身的修补/修改/自定义版本），因此可能会对这些页面进行一些分组。 --DavidManura

[LuaAddons] 用于索引“面向 Lua 用户的事物”，包括库、文档、开发工具和发行版。 “Lua 附加组件”可能不是最好的术语，但此页面的第一句话阐明了其意图，而且它比“面向 Lua 用户的事物”更容易说。 --JohnBelmonte

将这三个模糊界定的部分视为：此维基的内容 (LuaDirectory)、关于 Lua 本身的外部链接 (LuaLinks)，以及关于面向 Lua 用户的所有其他事物的外部链接 (LuaAddons)。 我认为在介绍此页面的第三段中已经足够清楚地说明了这一点。 --JohnBelmonte

我一直觉得内部链接和外部链接之间的区别对于组织目的来说是人为的。 一些事物甚至同时存在于内部和外部（例如，MetaLua 与 [Metalua]）。 例如，我最近将语言比较部分从 LuaLinks 移动到了 LuaComparison。 --DavidManura

在 HomePage 上，特色页面与起点有何不同？ 例如，为什么 LuaDirectory 不是特色页面？ --DavidManura

起点提供了维基的主要索引页面以及提供反馈的地方。 这些页面从定义上来说是通用的，永远不会是特色页面。 --JohnBelmonte

我认为 LuaDirectory 的内容更适合放在首页，而不是作为子链接。目前的结构感觉有点倒置，让人感到困惑。--DavidManura

如果合适，通常会用“Lua”作为前缀，并且只将首字母大写（例如 LuaFaq 而不是 Faq 或 LuaFAQ）。但也有一些例外，例如 LuaPowerPatches 和 IoLanguage。

users.lua.org 可能比 lua-users.org 更合理，不过这个问题已经在这里讨论过：https://lua-users.lua.ac.cn/lists/lua-l/2001-07/msg00208.html。

LibrariesAndBindings 和 LuaForge 在目的上有一些重叠。 LuaForge 规模更大（包含 215 个项目），但并非所有注册的项目都是模块。然而，并非所有 Lua 项目都注册在 LuaForge 上。有些项目是混合型的：注册在 LuaForge 上，但文件存储在其他地方。一些模块只是在维基的 SampleCode 部分非正式地维护。一些模块注册在 LuaRocks 数据库中。目前还没有像 CPAN 那样用于注册模块的中央位置。

建议的 Lua Wiki 指南

以下是我对这个维基的一些建议或我认为的良好实践。--DavidManura

(1) 所有代码或页面都应该标记其目标运行的 Lua 版本。

一个例子 

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

过去的一个问题是，人们在维基上添加了 Lua 4 的例子。然后 Lua 5.0 接着是 5.1 发布了，它们通常无法识别 Lua 4（有时甚至无法识别 Lua 5.0）。然而，Lua 4 的代码仍然保留在维基上，而且没有提示读者这一点。Asko 同意 [1]。标记版本将有助于解决这个问题。事实上，这已经在 LuaPowerPatches 中强制执行。此外，如果你发现旧代码，但目前没有时间修改它，我建议用 VersionNotice 标记它。

理想情况下，我们希望将维基上的旧 Lua 代码转换为最新版本的 Lua。不过，我认为保留旧版本作为历史参考的脚注是可以的，甚至可能是可取的。只需将其标记为旧版本即可。

(2) 正确的交互式 Lua 会话语法高亮将非常有用，因为这在维基上经常出现。你可以使用常规的“Lua”语法高亮，它通常可以正常工作，但并不总是有效。 

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

维基使用的 Perl 代码的一个版本位于 LuaToHtml。我想提供一个补丁，但请查看那里的评论。

(3) C 语言语法高亮。

这将有助于许多 C 代码示例。 RiciLake 在 GuestBook 上也提出了这个请求。

(4) 页面创作风格建议

基于对大量页面的编辑，我认为作者和编辑应该遵循以下最佳实践。使用 Lua 语法高亮功能。将代码示例向右缩进（如上面的 Lua 示例所示）以将其与周围文本区分开来。避免使用制表符，而是使用两个空格（或三个空格），遵循 Lua 手册和 PiL 书籍的风格，我认为这最适合维基媒体。避免在表达式中使用额外的空格，例如 x = f( x, y ) or { a , b }，而是使用 x = f(x, y) or {a, b} - 通常使用与维基上其他页面一致的最传统风格。实际上，我刚刚发现了这个：SourceCodeFormatter。

一些页面集在性质上足够相似，因此属于某些类别，在这种情况下，可以强制执行一些一致性。一个例子是 SampleCode。

(5) 维基结构

一些关于维基整体结构的过去评论在 WikiStructure 中，但我仍在形成我对整体结构的看法，目前，优先级更高的是审查大部分维基内容，如下所述。

(6) 定期审查内容。

维基上的内容应定期审查，以确保质量、一致性和内容的正确性。随着 Lua 的变化和 Lua 社区的变化，发布的内容可能会随着时间的推移变得不那么正确（如上面的 Lua 4 案例所示）。我目前正在对大部分维基内容进行自己的审查。

要删除的页面

这些页面可以删除。

要移动的页面

这些页面可以移动。

其他

1) 可以清理/更新它。大多数链接将直接指向 LuaAddonsArchive。
2) 可以直接放弃/移除它。所有有用的内容（即 BEOS 和 Linux ARM/SH3 链接）将被整合到 LuaDistributions 中。
我投票支持第二种方案。--DmitryGaivoronsky

Lua目录和分类

请在我的用户页面查看新的 LuaDirectory 结构提案：DmitryGaivoronsky。注意
一些评论和章节标题听起来很奇怪（请原谅我的英语不好），应该进行修正。
一些评论缺失。
一些章节还没有经过仔细思考，需要更多整理；一些页面可能被错误分类。
我发明了一个策略（并且发现它很方便），即用斜体标记所有包含目录的页面链接，即链接列表或提交表单。不过，它也可能受到批评。
在没有维基引擎对分类的原生支持的情况下，创建和维护一致的维基结构可能非常困难。--DmitryGaivoronsky

我认为 LuaProgramming 和 LuaCoding 这两个术语本质上是同义词（即编写源代码）。LuaProgramming 页面上的链接涉及在 Lua 源代码中使用和表示结构和模式的方法。 LuaCoding 页面上的链接似乎更多地涉及围绕 Lua 代码的使用和开发的过程，基本上是软件工程[2] 方面，甚至可能超出了 Lua 语言本身。因此，我初步建议将页面名称改为 LuaProgramming 和 LuaEngineering?。--DavidManura

与之前类似的重组一样，我不能说我赞成。内容在各个页面之间变得过于分散，层次结构越来越深，交叉引用越来越多。这击中了维基的弱点，尤其是这种简单的维基实现。是的，单一页面并不完美，但它们有优点：减少了“迷路的地方”，减少了到处添加导航辅助的愿望，在一个视图中保留了更广阔的画面，减少了重复目录指南或策略的需要（或者省略它们并处理后果）。限制（例如将层次结构限制为 2 层）是有意义的。**我不同意使用斜体来表示索引页面引用——这有点过度使用格式，收益甚微。我真的会根据链接是否是索引来决定是否访问它吗？——JohnBelmonte

我理解提议的重组的理由，但我确实有一些 John 的担忧。虽然LuaLanguage、LuaProgramming 和 LuaCoding（也称为 LuaEngineering?）形成了一个自然的进展（定义语言、使用语言和组织语言的使用），但 LuaDomains 可能与其他页面密切相关。

我认为，也许，作为一个规则，用户不会想到要访问的索引页面不应该存在。我认为，典型的用户来到维基是为了询问诸如“如何在 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，但维基技术并不适合更少的地方，而是适合更多的地方。为了避免迷失（无论是读者搜索/导航还是编辑者构建/维护），人们发明了类别。（坦白地说，所有这些主要都是为了模仿 MediaWiki 类的类别[3]... 你用过它们吗？）。为了避免重复，人们发明了模板。（你用过它们吗？）我认为试图将维基结构适应维基引擎并不是一个好主意。相反，我们应该考虑将维基引擎适应维基结构。
斜体的理由。维基技术建议，出于导航和可观察性的目的，每个页面都应该至少列在一个类别/目录/索引中。斜体化的想法源于需要标记被认为是此类类别的内容。
层次结构内部的交叉引用不是一个弱点。事实上，它是一致分类的必要特征。类别的层次结构不能表示为树；它是一个没有循环的有向图[4]。
将一个页面的层次结构限制在 N 个深度级别是一个合理的方法。不是强制在一个页面上浅化它，而是将深层分支提取到单独的页面。（我建议最大深度为 4，将 5 级分支切割成例如 3 级和 2 级部分）。跨页面层次结构的深度不应受限制。
DavidManura，'工程' ~= '软件工程'。对我来说，LuaEngineering? 让人想起 CAD/CAE 系统（...在 LuaDomains 中的某个地方）。--DmitryGaivoronsky

是的，我在 10 多年前在一个维基上使用过维基类别。你甚至可以在像这样的简单维基上做到这一点，方法是让多个页面引用一个类别页面并使用反向引用功能。但当我 2001 年开始 lua-users 维基时，我刻意不引入这种复杂性，并避免我在经验中遇到的许多类似的维基混乱陷阱。当时我对功能丰富的维基引擎非常熟悉，并在随后的几年里也一直如此。即使从这个简单的引擎开始，我也花了一些精力将功能提取出来，以保持简单。组织和分类事物的工作可能会做得过火，而内容的重要性——真正的价值——就会丢失。你从今年年初开始进行的重组违背了我对该网站的意识目标，但我不想成为独裁者。我重视大卫的意见，因为他多年来一直非常关心这个维基的内容和组织，所以我希望你考虑他的建议和反馈。** 我认为你误解了我对限制层次结构级别的意思。我指的是页面间层次结构，而不是页面内的标题层次结构。换句话说，我想要更少的页面，而不是更多。--JohnBelmonte

(软件) 工程/构建可能只是一个微弱的改进。维基在某种程度上支持类别（例如 面向对象编程）。点击页面标题以提供按字母顺序排序的链接到该页面的页面列表（反向链接）的功能相当低级，大多数用户可能并不清楚。此外，“A 链接到 B”比“A 是 B 的子/超类别”更一般的关系。但是，此功能对于维基作者来说非常有用，可以检查页面是否正确交叉链接和父级（如果没有，则手动修复它）。--DavidManura

Lua 文档（Lua 附加组件 的一部分）和 Lua 语言 在目的上略有重叠。此外，鉴于约翰在上面对“关于 Lua 本身的外部链接 (Lua 链接)，以及关于 Lua 用户其他所有内容的外部链接 (Lua 附加组件)”的描述，以及我的描述“Lua 语言、Lua 编程 和 Lua 编码（也称为 Lua 工程?）形成一个自然进程（定义语言、使用语言和组织语言的使用）”，人们至少可以部分地类比 Lua 链接 与 Lua 语言/Lua 文档 相似，而 Lua 附加组件 与 Lua 编码 相似。我认为 Lua 附加组件（包括 Lua 文档、Lua 工具、库和绑定 等）倾向于处理具体的事物（文件/库/插件/实用程序），而 Lua 语言 和 Lua 编码 倾向于处理更多主题、问题、描述和思维过程。 Lua 领域 可能是两者的结合。--DavidManura

我认为 Lua 强力补丁 应该作为 Lua 附加组件 中的顶级链接，而不是在主页上（尽管“补丁”仍然可以在 Lua 附加组件 链接的描述中列出）。补丁与发行版、实现、编辑器插件、库和工具处于同一级别。--DavidManura

Lua 强力补丁 是这个维基中对 Lua 社区影响最大的页面。我很遗憾看到它从主页上的特色链接中删除。--JohnBelmonte

我也对此有一些犹豫。 Lua 强力补丁 可以成为特色项目，尽管它已经包含在 Lua 附加组件 中。一些其他的 Lua 附加组件，例如 库和绑定、Lua 发行版 和 Lua 实现 也非常重要。但是，与其他语言相比，补丁在 Lua 中具有特殊的意义，因此我理解人们希望保持它的突出地位。我对主页上补丁的当前呈现方式并不完全确定。我认为 学习 Lua 和 Lua 比较 也很重要，应该成为特色项目，尽管它们已经在 Lua 常见问题解答 中很突出。--DavidManura

我目前对LuaDirectory页面在DmitryGaivoronsky中的拆分没有强烈的意见。但是，如果它被进一步缩减（例如，将社区部分移到一个新的页面LuaCommunity?），那么LuaDirectory很可能可以合并到HomePage中，这符合我在WikiStructure的顶部部分的想法。--DavidManura

我更希望主页保持我最初编写的样子——简洁，链接少于10个。--JohnBelmonte

在DmitryGaivoronsky中提出的目录结构将非常广泛的视图（例如LuaLanguage，LuaAddons，LuaDomains，...）与更具体的链接（例如GoogleSummerOfCodeIdeas）混合在一起。我建议选择其中一种。以下是仅使用广泛链接的示例（大约10个链接）。--DavidManura

从逻辑上讲，简介应该属于LuaLanguage。我把简介和社区放在顶层主要是为了方便和填补空间。它们可能太小，不值得单独创建页面；但如果你觉得这样更一致，我不介意。但是，我认为我们应该避免在注释中添加任何链接——它们几乎不会被直接使用，但会使列表更加混乱。--DmitryGaivoronsky

这很有道理。下面是重写后的版本。顶层列表是主要类别部分。第二层列表是这些部分中重要的特色页面（如果有的话）。我不确定是否需要将 LuaProgramming 和 LuaDomains 分开（参见上面关于 LuaDomains 的先前评论）。--DavidManura

我建议不要选择任何“重要”或“特色”页面。这是一个非常主观的问题。应该意识到，如果 lua-users 变得更受欢迎，这会导致维基战争（过滤 -> 恢复 -> 审查）。毕竟，LuaDirectory“是此维基中所有 Lua 内容的顶级目录”，而“特色页面”部分位于 HomePage。
另一个选择是只保留和收集第二层中斜体链接（即目录）。这是一个正式的标准，很容易维护和执行。（但对于舒适使用来说可能过于正式——这就是为什么在我的原始提议中我允许了一些例外。）
可能不清楚，但是……所有这些都只是试图发明已经发明的东西。我仍然在暗示 Mediawiki 类的类别（正如俄罗斯人所说，“我们为什么要尝试发明自行车？”）。--DmitryGaivoronsky 

The task of organizing and categorizing things can be overdone, and the importance of content-- the real value-- lost.
--JohnBelmonte
当大多数内容都埋藏在地下时，谈论内容的重要性就变得相当困难。这个维基页面确实有很多页面，但其中很多页面几乎没有被普通用户看到的可能性。（我发现用 wget 一次性获取所有 lua-users 的内容比按照超链接阅读要方便得多。）在一个堆积如山的无组织事物中（俄罗斯谚语：“在干草堆里找一根针”），很难找到任何东西。因此，我认为正确的问题是：引擎是否可以扩展到如此多的页面？（你能证明吗？）--DmitryGaivoronsky

DavidManura，我们可以将LuaProgramming中的算法部分与LuaDomains合并。这将为我们提供LuaAlgorithms?。但是...并非所有LuaDomains中的条目都是真正的 Lua 算法。（因此，从形式上讲，LuaDomains和LuaAlgorithms?是并行的类别，而LuaAlgorithms?是LuaProgramming的子类别。）--DmitryGaivoronsky

另请参阅

最近更改 · 偏好设置
编辑 · 历史
最后编辑于 2009 年 11 月 27 日下午 4:49 GMT (差异)