Hacklang:为什么用内置类型替换了容器类? [英] Hacklang : why were container classes replaced with built-in types?

问题描述

只需引用黑客文档中的一句话:

Just a quote from hack documentation :

旧版矢量，地图和设置

Legacy Vector, Map, and Set

在新代码中应避免使用这些容器类型；使用字典，键集，而是使用vec.

These container types should be avoided in new code; use dict, keyset, and vec instead.

在Hack的早期，图书馆提供了可变且不变的通用类类型，称为:Vector，ImmVector，Map，ImmMap，Set和ImmSet.但是，这些已被vec，dict和keyset取代，建议在所有新代码中使用它.每个通用类型都有一个相应的文字形式.例如，类型为的变量向量可以使用向量{22，33，$ v}进行初始化，其中$ v是int类型的变量.

Early in Hack's life, the library provided mutable and immutable generic class types called: Vector, ImmVector, Map, ImmMap, Set, and ImmSet. However, these have been replaced by vec, dict, and keyset, whose use is recommended in all new code. Each generic type had a corresponding literal form. For example, a variable of type Vector might be initialized using Vector {22, 33, $v}, where $v is a variable of type int.

我想知道为什么要进行此更改.我的意思是，PHP的弱点之一是它的oop标准库不好.例如: str_replace 和 array_values 方法不在字符串/数组类型本身之外.PHP标准库不一致，有时我们必须将数组作为第一个参数传递，而其他时候则作为第二个参数传递.

I wonder why this change was made. I mean, one of PHP weaknesses is that it has bad oop standard library. Ex : str_replace and array_values methods are outside of the string/array type itself. The PHP standard library is not consistent, sometimes we must pass the array as the first parameter, other times as the second...

我很高兴看到Hack为集合引入了真正的OOP封装.
您知道为什么他们退后一步并编写实用程序类，例如 C \ ， Dict \ ， Keyset \ 和 Vec \ ?
将来还会有一些添加方法来为内置类型添加方法(例如: Str \ starts_with => "toto"-> startsWith("t"))?

I was glad to see that Hack introduced true OOP encapsulation for collections.
Do you know why they stepped back and wrote utility classes such as C\, Dict\, Keyset\ and Vec\ ?
Will there be in the future an addition to add methods to built-in types (ex : Str\starts_with => "toto"->startsWith("t")) ?

推荐答案

基于 Dwayne Reeves的博客文章介绍了HSL ，似乎主要的优点是数组是本机值，而不是对象.这有两个重要的后果:

Based on Dwayne Reeves' blog post introducing HSL, it seems that the main advantage is the fact that arrays are native values, not objects. This has two important consequences:

1. 对于用户而言，值通过参数交叉时的语义是不同的.对象作为引用传递，并且变异会影响原始对象.另一方面，值是在传递参数后在写入时复制的，因此没有引用(最终将完全在Hack中被禁止)，被调用者无法更改调用者的值，但更为严格的

1. For users, the semantics are different when the values cross through arguments. Objects are passed as references, and mutations affect the original object. On the other hand, values are copied on write after passing through arguments, so without references (which are finally to be completely banned in Hack) the callee can't mutate the value of the caller, with the exception of the much stricter inout parameters.

本文引用了可变容器(向量，集合等)的不变性，并且通常指出了共享的可变状态耦合如何将功能紧密地结合在一起.本文中讨论的健全性问题有些争议，因为还有 也是不可变的对象容器(ImmVector，ImmSet等)，尽管由于这些接口是在用户区中编写的，所以方差将函数类型签名放入了严格的约束.与此有明显的区别: ImmMap< Tk，+ Tv> 在 Tk 中是不变的，仅是因为(function(Tk):Tv)吸气剂.同时，由于固有的针对写时复制的突变保护， dict< + Tk，+ Tv> 在两个类型参数中都是协变的.

The article cites the invariance of the mutable containers (Vector, Set, etc.) and generally how shared mutable state couples functions closer together. The soundness issues as discussed in the article are somewhat moot because there were also immutable object containers (ImmVector, ImmSet, etc.), although since these interfaces were written in userland, variance boxed the function type signature into tight constraints. There are tangible differences from this: ImmMap<Tk, +Tv> is invariant in Tk solely because of the (function(Tk): Tv) getter. Meanwhile, dict<+Tk, +Tv> is covariant in both type parameters thanks to the inherent mutation protection from copy-on-write.

对于编译器，可以快速分配静态值，并且可以在服务器的整个生命周期内保持不变.另一方面，对象通常具有任意复杂的构造例程，并且看来收集对象不会是特殊情况.

For the compiler, static values can be allocated quickly and persist over the lifetime of the server. Objects on the other hand have arbitrarily complicated construction routines in general, and the collection objects weren't going to be special-cased it seems.

我还要提到的是，在大多数使用情况下，即使在代码样式方面，差异也很小:例如-> 参考链可以直接替换为 |> 管道运算符.在特权标准功能"之间不再存在边界.以及针对集合类型的自定义用户功能.最终，集合类型当然是 final ，因此它们的客观性质仍然不能为最终用户提供任何实际的分层或多态优势.

I will also mention that for most use cases, there is minimal difference even in code style: e.g. the -> reference chains can be directly replaced with the |> pipe operator. There is also no longer a boundary between the privileged "standard functions" and custom user functions on collection types. Finally, the collection types were final of course, so their objective nature didn't offer any actual hierarchical or polymorphic advantages to the end user anyways.

这篇关于Hacklang:为什么用内置类型替换了容器类?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！