为什么Erlang元组模块有争议？ [英] Why Erlang tuple module is controversial?

问题描述

在 Erlang中的参数化模块问了一个类似的问题，它是关于什么的。我的问题是关于为什么？

OTP技术委员会 - 影响R16的决定包含有关此问题的董事会决定，但我不知道决定背后的原因。

编程中的状态模块Erlang 2ndEdition由Joe Armstrong 详细介绍了这个功能，但我看不到作者的态度。

如果我们阅读官方文档函数调用，我们看到这个功能是有意地被撇除的。事实上，官方文件强烈不鼓励使用此功能，请参阅效率函数调用。如果是这样，为什么乔·阿姆斯特朗在他的书中提到这样的特征？

我认为这个功能非常棒。如上所述，我的客户端代码可能如下所示

  Obj：find（Key），
 Obj： is_key（Key），
  

然后，我们不在乎是否 Obj 由 dict：new（）或 gb_tree：new（）创建，不幸的是， dict 和 gb_tree 不共享一致的界面，例如我们有 gb_tree：lookup 而不是 gb_tree：find 。

解决方案

我无法告诉你在一切控制之内的讨论是什么，但是我可以告诉你为什么我从来没有考虑过使用这个功能：

1. 不合适。 Erlang是功能性的，这是一个奇怪的OOP风格的结构介绍 - 有胳膊和腿的事情。我不喜欢我的代码与自己冲突。



2. 它引入了句法复杂性和语义上的严重性，但没有给我新的超级大国。

   
   
   
   
   

   • 复杂性：

     
     
     1. 属性 X Foo 等于10或20现在？
     
     
     2. 为什么我写 dict：is_key（Value，Thingy）这里，然后 Thingy：is_key（Value）在那边？
     
     
     3. 我真的想要遇到像 dict的代码：dict：is_key（Key，Foo：get_value（Key2））所有的时间？
     
     
     4. 我已经有一个流程设计来实现这一点，并将状态的复杂性从流程代码中移出，并进入异步消息的世界（在代码中，我可以处理单个调用中的时间孤立的快照的功能）...
     
     
     5. 如果我真的需要这不是过程字典是什么？
     
     

   
   

   • 歧义：

     
     
     1. 这是一个'thi ng'我正在调用一个方法或一个模块函数？
     
     
     2. 等等，这不是功能吗？
     
     
     3. 可以把它放在一个关闭中，并把它从别的地方发送出去吗？如果别的地方是另一个节点怎么办？我必须开始关心这个突然吗？
     
     

   
   



3. 引入不透明状态（不好）而不是ADT（好的，我们已经有的东西）。



4. 没有人使用这个，所以为什么浪费努力支持它，特别是考虑到角落


5. 这里的收益只是被察觉到对于不能与Java-isms相关的人来说，这是一个好处。在 Foo之间没有太大的区别：is_key（Key）比 dict：is_key（Key，Foo）除了在一读完之前我确实的事实，即使在完全没有上下文的情况下，正在操作的数据对象在第二个版本中绝对是一个dict。

Erlang的符号赋值（又称单一赋值）是伟大的，为什么要破坏？ / p>

A similar question was asked Parameterised Modules in Erlang, it is about "what". My question is about "why"?

OTP Technical Board - Decisions affecting R16 contains the board decision about this issue, but I don't know the reason behind the decision.

Stateful Module in Programming Erlang 2ndEdition by Joe Armstrong introduces this feature in detail, but I don't see the author's attitude.

If we read the official document Function Calls, we see this feature is deliberately skimmed. In fact, the official document strongly discourages using this feature, refer to efficiency function calls. If so, why Joe Armstrong mentions such feature in his book?

I think this feature is awesome. As the above book mentioned, my client code could be like below

Obj:find(Key),
Obj:is_key(Key),

Then, we don't care whether Obj is created by dict:new(), or gb_tree:new(), unfortunately, dict and gb_tree do not share a consistent interface, e.g. we have gb_tree:lookup instead of gb_tree:find.

解决方案

I can't tell you what the discussion was within the Great Cabal That Controls Everything, but I can tell you a few reasons why I never have considered using this feature:

1. It doesn't fit. Erlang is functional and this is a weird introduction of OOP-style structs-that-have-arms-and-legs sort of thing. I don't like my code to clash with itself.

2. It introduces syntactic complexity and semantic abiguity but grants me no new superpowers.

   • Complexity:

     1. "Is attribute X of Foo equal to 10 or 20 right now?"
     2. "Why do I write dict:is_key(Value, Thingy) here and then Thingy:is_key(Value) over there?
     3. "Do I really want to encounter code like dict:is_key(Key, Foo:get_value(Key2)) all the time?"
     4. I already have an army of processes designed to do just this and move the complexity of state out of the process code and into the world of asyncronous messages (in code I can deal with an isolated snapshot of time within a single call of a function)...
     5. If I really need this isn't that what the process dictionary was for?

   • Ambiguity:

     1. "Is this a 'thing' I'm calling a method of, or a module function I'm calling?"
     2. "Wait, wasn't this supposed to be functional?"
     3. "Is it OK to put that in a closure and send it off somewhere else? What if 'somewhere else' is another node? Do I have to start caring about that suddenly?"

3. This introduces opaque state (bad) instead of an ADT (good, and something we already have).

4. Nobody uses this, so why waste effort supporting it, especially considering the corner cases it might bring up. That's support overhead and effort I would rather see go into features that we all do use.
5. The "gain" here is only perceived as a benefit to people who can't bear to part with Java-isms. There isn't much difference between Foo:is_key(Key) than dict:is_key(Key, Foo). Other than the fact that I am certain on first reading, even in a complete absence of context, that the data object being operated upon in the second version is definitely a dict.

Erlang's symbol assignment (aka "single assignment") is great, why destroy that?

这篇关于为什么Erlang元组模块有争议？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！