raku - raku 角色中的签名限制

Question

也许我遗漏了一些东西，但我想知道这段代码是否有充分的理由
编译

role L {
  method do-l (Int, Int --> Int ) { ... }
}

class A does L {
  method do-l (Int $a, Real $b --> Str) {
    .Str ~ ": Did you expect Int?" with $a + $b
  }
}

my $a = A.new;

say $a.do-l: 2, 3.323

这将输出

5.323: Did you expect Int?

我很好奇是否有人知道编译器至少抛出一些的方法
带有角色签名的警告 L .

Answer 1

throw some warning with the implemented signature of the role L.

如果你在方法声明前加上 multi :

role L {
  multi method do-l (Int, Int --> Int ) { ... }
}

有了这个，您的程序将显示:

===SORRY!=== Error while compiling ...
Multi method 'do-l' with signature :(A: Int $, Int $, *%_ --> Int)
must be implemented by A because it is required by a role ...

I'd like to know if there is a good reason why this code should compile [without the multi]

我认为设计意图是支持多态组合的两个概念:

没有 multi , 执行只与具有正确名称的方法的存在有关；参数被忽略。

与 multi , 强制还包括名称和所有参数 ( or some )。

我个人认为是否有充分的理由:

支持两种风格的方法多态？ 有时强制严格遵守签名是有帮助的。有时它会妨碍。

通过 multi 区分它们? 完全签名强制要求实现类/角色具有具有完全相同签名的方法。但是如果一个实现类/角色想要处理一个 int 怎么办？而不是 Int对于参数？乐妥协了。如果实现类/角色具有完全兼容的方法，它也可以有变化。传达这一点的完美方式是在 stub 方法前加上 multi .

有默认的名称只有多态性吗？ 我们本可以选择 multi语义作为默认值，并让用户编写 only如果他们只想命名多态性，则使用前缀。但这会扭转通常的情况(即忽略 stub 方法)。更一般地说，Raku 的目的是为其功能提供广泛的限制，从轻松到紧张，并为任何给定的功能选择一个默认值，这些功能是根据多年来用户的反馈判断正确的。

如果默认值看起来不对怎么办？如果现有的限制范围不够怎么办？如果一组认为我们应该向左走而另一组认为我们应该向右走怎么办？

Raku 拥有 (imo) 卓越的治理机制来支持用户驱动的语言进化。在顶层有像 the braid architecture 这样的元素.在底层有类似 versionable types 的元素.中间是 RoleToClassApplier 之类的元素它调解将角色应用于类的过程，这是需要找到所需方法或类的构造将失败的点。简而言之，如果语言不能按照您想要的方式工作，包括诸如限制之类的事情，您至少可以在原则上对其进行更改。