哪些类型的系统足够强大来表达这一点？

Question

假设我们定义了一个这样的接口：

interface Hashable {
   int hash();
}

现在我们可以创建实现这个接口的类。例如 List 类：

class List<T> : Hashable {
   int hash(){
      int h = 0;
      foreach(x in this){
         h = combineHash(h,x.hash());
      }
      return h;
   }
}

问题是我们对 List 内的元素调用 hash，因此 T 必须是 Hashable。所以我们必须这样做：

class List<T : Hashable> : Hashable {
   ... same here ...
}

另一方面，我们也希望能够使用不可散列的元素构造列表。在这种情况下，我们根本不希望 List 实现 Hashable。所以：

List<AHashableType>      is itself Hashable
List<NotAHashableType>   is not Hashable

此外，我们希望哈希方法是多态的（OO 类型的多态，而不是参数多态）。因此，如果我们构造一个包含 Bar 和 Baz 的 List，其中 Foo 是Hashable、Bar 和 Baz 是 Foo 的子类型，具有不同的 hash() 方法，那么List.hash() 应在运行时调用正确的哈希方法。

这似乎是语言应该能够表达的基本事物。相同的模式出现在不同的情况下，例如使用 ToString() 和 IComparable。到目前为止，我还没有找到一种语言和该语言的解决方案，可以让我以类型安全的方式表达这一点。您知道这样的语言和该语言的解决方案吗？ Haskell 的类型类非常接近，但不幸的是这些是在编译时调度的。

Answer 1

不幸的是，您需要一些泛型的条件类型约束（注释模板可以通过部分专业化和私有继承来支持这一点）。我不知道有哪种静态类型语言具有它们，但可以通过扩展方法使用猴子补丁来解决。这是 C# 中的示例。

public static int GetHash<T>(this List<T> list) where T:IEquatable<T>
{
      if(list == null) throw new ArgumentNullException("list");
      int h = 0;
      foreach(var x in list){
         h = CombineHash(h,x.GetHashCode());
      }
      return h;
}

组合哈希 (CombineHash) 组合您的哈希码。
请注意，C# 中的每个方法实际上默认都有一个哈希码，但 IEquatable 是一个将 GetHashCode 指定为成员的接口。
因此 List. 可以调用 GetHash，但 List

interface IFoo{
    string Bar();
}
class Foo:IFoo{
    public virtual string Bar(){return "Foo";}
}
class Baz:Foo{
     public override string Bar(){return "Baz";}
}
public static string Bar(this List<T> list) where T:IFoo
{
    if(list == null) throw new ArgumentNullException("list");
    StringBuilder sb = new StringBuilder();
    foreach(var x in list){
       sb.Append(x.Bar());
    }
    return sb.Bar();
}

这里，由于我们将 T 约束为 IFoo，所以我们现在可以调用它List、List 或 List 上的方法，但不是List as int 未实现 IFoo。
例如

public static void SomeMethod()
{
      Console.WriteLine(new List<IFoo>{new Baz(),new Foo()}.Bar()); //compiles
      Console.WriteLine(new List<int>{1,2,3,4,}.Bar()); // does not compile.
}

Answer 2

也许我误读了OP，但似乎有必要在编译时知道给定的List是否是Hashable。否则，在非 Hashable List 上调用 hash() 会发生什么情况？

不过，我确信 CLOS 存在解决方案。 （多重分派肯定会派上用场，而且我隐约意识到它处理子类的更具表现力的方式。）

Answer 3

我认为将您描述的两个问题分开是有用的。第一个是有条件地实现接口。就像你说的，Haskell 类型类就是这样做的。它看起来像：

class Hashable t where
  hash :: t -> Int

instance Hashable Int where
  hash i = i

-- Reads as "(List t) is Hashable if t is Hashable"
instance (Hashable t) => Hashable (List t) where
  hash l = ...

第二个问题是 OO 多态性，您可以在 Haskell 中使用类似函数指针的机制来模拟它。

-- Pretending we have some kind of OO method dispatch here
instance Hashable Foo where
    hash foo = foo.computeHash()

class Foo
   computeHash()

我读过几篇论文，将这种“条件接口实现”添加到类似 Java 的语言中。其中之一是 JavaGI (http://homepages.cwi.nl/~ralf/JavaGI/)，它还增加了为最初未定义的数据类型（如 Haskell 类型类）实现接口的能力。我不记得另一篇论文叫什么了。

Answer 4

恕我直言，您描述的问题是在许多情况下违反接口隔离原则的一个很好的理由，特别是在有限类型的系统（例如 Java 或 .NET 的系统）中。虽然能够使用类型检查作为确保仅要求对象执行它们能够执行的操作的手段具有很大的价值，但并非所有能力问题都可以在程序运行之前决定。在许多情况下，代码将收到对具有可选功能的对象的引用，如果存在，则应使用该对象，如果不存在，则应解决该问题。如果接口包括用于此类可选能力的方法，以及确定是否应使用这些方法的方法，则此类对象的组合或聚合同样可以公开此类可选能力。如果接口仅包含实现者保证能够执行的操作，那么不可变聚合必须在构造时识别它想要宣传的所有功能，而可变聚合不能宣传它们不需要从每个项目中获得的任何功能已添加。

是否存在接口的某些实现具有而其他实现不具有的能力，以及是否很可能相同的对象必须处理具有该能力的事物和不具有该能力的事物，并且应该能够使用当存在这种能力时，我建议在界面中包含该能力以及确定该能力何时可用的方法。例如，如果一个集合标识 IFoo 实例，其中一些实例可以 Boz()，并且集合本身应该实现 IFoo 并调用 Boz 时，集合上的 >Boz 才应该是合法的，我建议让 IFoo 包含 Boz() 以及 CanBoz 属性。 CanBoz 属性可以询问集合中的每个项目是否可以 Boz，只有当所有包含的项目都这样做时才返回肯定。您将失去可能来自更严格的类型检查的编译时保证，但您将能够在静态类型检查不允许的情况下使用该方法。