问题描述
我正在通过mochiweb源代码,看到我以前从未使用过的东西。模块声明特别是在mochiweb http库中找到的 mochiweb_request
和 mochiweb_response
模块。这是模块的开始:
I was going through mochiweb source code and got to see something i never used before. The module declaration especially in mochiweb_request
and mochiweb_response
modules found in the mochiweb http library. Here is how the module begins:
-module(mochiweb_request,[Socket, Method, RawPath, Version, Headers]).
-author(...).
然后在模块中看到 get(socket) - > Socket; get(method) - > Method; ....
这让我感到困惑。当我尝试获取这些模块之一的模块信息时,编译器添加了一些内容: {abstract,true}
返回到:
mochiweb_request的:MODULE_INFO()
。实际上,他们的文档将这些模块称为抽象模块
。
Then in the module you see get(socket) -> Socket;get(method)-> Method; ....
This has confused me. When i tried getting the module info of one of these such module, the compiler had added something: {abstract,true}
in the return to: mochiweb_request:module_info().
. Infact, their documentation refers to these modules as abstract modules
.
我已经搜索了google,并发现了一个参数化的论文模块:链接很大,但如果您按照
I have searched google and found a paper on parameterised modules: the link is so big but am sure you will get the paper if u follow on here
这些模块不能直接调用,但是通过他们自己的实例来调用。它使模块的行为就好像他们很有趣。我已经意识到它在运行时系统中的非官方功能。令我感到困惑的是,mochiweb的人正在使用它很好!在mochiweb模块中,您会发现自己的写作:
These modules cannot be called directly but are called through instances of them selves. It makes modules behave as though they were funs. I have come to realise that its an unofficial feature in the runtime system. What confuses me is that the mochiweb guys are using it well!. In a mochiweb module, you will find your self writing:
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(\\\
显示一个复杂的数据结构(一个元组),它的
\t Req =〜p〜n,[Req])元素(1,Req)== mochiweb_request
。这是有趣的!!!!!
问题1是:现在用于生产中是否稳定,或者我可以等到官方使用?
问题2是:如果没有官方的话,mochiweb的人有没有信心?
问题3:为什么还不是官方的? (因为,对我来说,它带来了一些面向对象的功能)
问题4:有没有人也在使用它?在哪些情况下他/她使用这些参数化模块?为什么?你可以指出我们看到或发布一些链接到一些源代码,以便我们可以在这个功能上找到更多的信息?
最后一个问题:没有在Erlang文档中找到这个功能关于。没有教科书,甚至。那么那些使用它的人怎么已经知道如何和为什么使用它?是否已经将Erlang Run时间系统的商业版本包含在中?
Trying to io:format("\n\t Req = ~p~n",[Req])
reveales a complex data structure (a tuple) whose element(1,Req) == mochiweb_request
. It is interesting!?!!!?
Question 1 is: Is it stable to use in production for now or i can wait till it is made official?
Question 2 is: How did the mochiweb guys get the confidence of using it, if it is not yet official?
Question 3: Why is it not yet official? (because, to me, it brings some Object Oriented features in)
Question 4: Is there anyone out there who has used it also? In which cases has he/she used these parameterised modules? Why? Can you point us there to see or post a link to some source code so we can find out more on this feature?
Last Question: No where in the Erlang Docs have i found this feature talked about. No text book, Not even home. So how did those who have used it already find out how and why to use it? Has it already been included in the commercial version of the Erlang Run time system found here?
推荐答案
问题1是:现在在生产中使用是否稳定,否则我可以等到官方使用?
它对生产使用非常稳定,现在已经有一段时间了。这不是官方标准的一部分。
Question 1 is: Is it stable to use in production for now or i can wait till it is made official?
It is very stable for production use and has been for some time now. It is not part of the official standard.
您将不得不向mochiweb球员询问。也许他们相信如果被拉扯,他们可以快速改变它。
You will have to ask the mochiweb guys for this. Perhaps they believe they can quickly change it if it was pulled.
因为它引起争议。不清楚它给语言带来什么好处,以及它如何使东西更容易做,所以P.模块有它的支持者和对手。因此,目前的观点是它是实现的一部分,所以人们可以玩它,看看他们是否觉得它使代码更容易阅读和写入。非官方意味着它可以被拉扯而不放弃,而且似乎Erlang的人保留这个权利。
Because it is littered with controversy. It is not clear what benefits it bring to the language and how it makes stuff easier to do, so P. Modules have its proponents and opponents. Hence, the current standpoint is that it is part of the implementation, so people can play with it and see if they feel it makes their code easier to read and write. The non-officiality means it can be pulled without deprecation though, and it seems as if the Erlang guys reserve that right.
个人偏见:我很喜欢它,但我永远不会用它来获得OOP功能到Erlang。 OOP是一个丑陋的庞然大物,没有编程的地方。只是苦难,会困扰你的程序,直到它们变成核心,像僵尸一样散步,生气。那时候唯一的解决办法就是霰弹枪。相反,我想使用它作为ML风格的函子 - 这更加静态,我觉得它符合Erlang的成语更好。
personal bias: I kind-of like it, but I won't ever be using it for getting OOP-features into Erlang. OOP is an ugly behemoth of utter crap that has no place in programming ever. It is just misery that will haunt your programs until they are rotten to the core, walking around like zombies and being mad. The only solution at that point is the shotgun. Rather, I'd like to use it as ML-style functors - which is more static in I feel it matches the idioms of Erlang better.
作者在几年前的Erlang会议上介绍了这件事情。从那以后,它一直是口碑等的组合。
The author presented the thing at an Erlang conference some years ago. Since then it has been a combination of word-of-mouth and so on.
这篇关于Erlang中的参数化模块的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!