raku 角色中的签名限制 [英] Signature restriction in roles in raku

问题描述

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

角色 L {方法 do-l (Int, Int --> Int ) { ... }}A类做L{方法 do-l (Int $a, Real $b --> Str) {" .str ~":你期待 Int 吗?$a + $b}}我的 $a = A.new;说 $a.do-l: 2, 3.323

这将输出

5.323:你期待 Int 吗?

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

解决方案

使用角色 L 的实现签名抛出一些警告.

如果在方法声明前加上 multi 前缀，你就会得到:

角色 L {多方法 do-l (Int, Int --> Int ) { ... }}

这样你的程序就会显示:

===SORRY!=== 编译时出错...带有签名的多方法'do-l' :(A: Int $, Int $, *%_ --> Int)必须由 A 实现，因为它是角色所必需的......

<块引用>

我想知道为什么这段代码应该编译[没有multi]

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

• 如果没有multi，强制执行只与具有正确名称的方法有关;参数被忽略.

• 使用multi，强制执行还包括名称和所有参数(或一些).

我个人对是否有充分理由的看法:

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

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

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

  立>

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

Raku 拥有 (imo) 卓越的治理机制来支持用户驱动的语言进化.在顶层有诸如编织结构之类的元素.在底层有像版本化类型.中间是诸如 代码Role> 中介将角色应用于类的过程，这是需要找到所需方法或类构建失败的点.简而言之，如果语言不能按您希望的方式工作，包括诸如限制之类的事情，您至少可以在原则上对其进行更改.

Maybe I'm missing something, but I'd like to know if there is a good reason why this code should compile

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

This will output

5.323: Did you expect Int?

I was curious if someone know a way for the compiler to at least throw some warning with the implemented signature of the role L.

解决方案

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

You get that if you prefix the method declaration with multi:

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

With this your program displays:

===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]

I think the design intent was to support two notions of polymorphic composition:

• Without the multi, enforcement only relates to existence of a method with the right name; parameters are ignored.

• With the multi, enforcement covers the name and all parameters as well (or some).

My personal take on whether there's a good reason for:

• Supporting two flavors of method polymorphism? Sometimes enforcing strict adherence to the signature is helpful. Sometimes it gets in the way.

• Distinguishing them via multi? Full signature enforcement requires that implementing classes/roles have a method with exactly the same signature. But what if an implementing class/role wants to handle an int instead of Int for a parameter? Raku compromises. Provided an implementing class/role has an exactly compliant method it can also have variations. The perfect way to convey this is to prefix a stubbed method with multi.

• Having the default be name only polymorphism? We could have chosen multi semantics as the default, and had users write an only prefix if they wanted name only polymorphism. But that would reverse the usual situation (i.e. ignoring stubbed methods). More generally, the intent is that Raku provides a wide range of stricture for its features, from relaxed to uptight, and picks a default for any given feature that is judged right based on feedback from users over the years.

What if the default doesn't seem right? What if the existing range of strictures isn't enough? What if one group thinks we should go left and another thinks we should go right?

Raku has (imo) remarkable governance mechanisms for supporting user driven language evolution. At the top level there are elements like the braid architecture. At the bottom level there are elements like versionable types. In the middle are elements like RoleToClassApplier which mediates the process of applying a role to a class, which is the point at which a required method needs to be found or the class's construction will fail. In short, if the language doesn't work the way you want, including such things as strictures, you can, at least in principle, change it so it does.

这篇关于raku 角色中的签名限制的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！