我正在浏览mochiweb源代码并且看到了以前从未使用过的东西。模块声明，尤其是在mochiweb http库中找到的mochiweb_request和mochiweb_response模块中。以下是模块的开始：
-module(mochiweb_request,[Socket, Method, RawPath, Version, Headers]). -author(...).
然后在模块中，您会看到get(socket) -> Socket;get(method)-> Method; ....
这让我很困惑。当我尝试获取其中一个这样的模块的模块信息时，编译器在返回时添加了一些内容：{abstract,true}：
mochiweb_request:module_info().。事实上，他们的文档将这些模块称为abstract modules。
我搜索了谷歌，发现了一篇关于参数化模块的论文：链接太大但是如果你继续here
，我相信你会得到论文。这些模块不能直接调用，而是通过它们的实例调用。它使模块表现得像是乐趣。我已经意识到它是运行时系统中的一个非官方特性。令我困惑的是，mochiweb的家伙们正在使用它！在mochiweb模块中，您将找到自己的写作：
loop(Req,_DocRoot)->
"/" ++ Path = Req:get_path(),
Body = Req:recv_body(),
Method = Req:get(method),
...,
....,
Response = Req:ok({"text.html;charset=utf-8",[],chunked}),
Response:write_chunk("Some text here....."),
...
尝试 io:format("\n\t Req = ~p~n",[Req])揭示其element(1,Req) == mochiweb_request的复杂数据结构（元组）。这很有趣！？!!!？
问题1是：现在在生产中使用是否稳定，或者我可以等到正式生产？
问题2是：如果mochiweb家伙尚未正式使用，那么他们是如何获得使用它的信心的呢？
问题3：为什么它还没有正式发布？ （因为，对我来说，它带来了一些面向对象的功能）
问题4：那里是否还有人使用过它？他/她在哪些情况下使用这些参数化模块？为什么？你能指点我们看看或发布一些源代码的链接，以便我们可以找到更多有关此功能的信息吗？
最后一个问题：没有在Erlang Docs中我发现了这个功能。没有教科书，甚至没有home。那么使用它的人怎么会发现如何以及为什么要使用它？是否已将其包含在Erlang Run time系统的商业版中here？<
p>
答案 0 :(得分：4)
在R16B中删除了它。来自the README：
OTP-10616实验性功能“参数化模块”（也称为 “抽象模块”）已被删除。对于应用程序 取决于参数化模块，有一个解析变换 可用于仍然使用参数化模块。该 解析变换可以在以下位置找到： http://github.com/erlang/pmod_transform
参数化模块的使用已经removed from Mochiweb，从版本2.4.0开始，虽然对以前参数化模块的调用看起来仍然相同，因为参数化模块（元组模块）的实现机制被保留向后兼容性。即使在Erlang/OTP 21.0中从编译器中删除了对元组调用的支持：
OTP-14497应用程序：编译器，erts
*可能不兼容*
已删除对“元组调用”的支持 运行时系统。元组调用是无证件的 不支持的功能，允许模块参数 使应用操作成为元组：
Var = dict:new(), Var:size()。这个“特征”经常引起混乱， 特别是当这样的呼叫失败时堆栈跟踪会 指出源中不存在的函数 代码。对于需要使用参数化模块的遗留代码 或者元组要求其他原因，有一个新的 编译器选项名为
tuple_calls。当这个选项是 给定，编译器将生成额外的代码 模拟模块所在的调用的旧行为 变量。
Mochiweb now uses the tuple_calls compiler option让这类代码继续发挥作用。
来自Technical Board decision announcing the end of parameterised modules：
董事会承认很多软件都依赖于此功能，尽管它一直是实验性的。当前的实现形式是不可接受的，并且参数化模块本身从未被接受为该语言的特征。该功能也与例如模块乐趣不兼容，并且未与OTP中的其他工具完全集成。
答案 1 :(得分：3)
它对于生产使用非常稳定，并且已经有一段时间了。它不是官方标准的一部分。
你将不得不向mochiweb家伙询问此事。也许他们相信如果它被拉了就可以迅速改变它。
因为它充斥着争议。目前尚不清楚它给语言带来了什么好处以及它如何让事情变得更容易，所以P. Modules有其支持者和反对者。因此，目前的观点是它是实现的一部分，因此人们可以使用它，看看他们是否觉得它使代码更容易阅读和编写。非官方意味着它可以在没有弃用的情况下被拉出来，似乎Erlang的人保留了这一权利。
个人偏见：我很喜欢它，但我永远不会用它来获取Erlang的OOP功能。 OOP是一个丑陋的庞然大物，在编程中没有任何地方。只是痛苦会困扰你的程序，直到它们腐烂到核心，像僵尸一样四处走动并疯狂。那时唯一的解决方案是霰弹枪。相反，我想将它用作ML风格的仿函数 - 这更加静态，我认为它更符合Erlang的习语。
几年前，作者在Erlang会议上提出了这个问题。从那时起，它就是口口相传等等。