Hạn chế chữ ký trong vai trò trong raku

Có thể tôi đang thiếu một cái gì đó, nhưng tôi muốn biết liệu có lý do chính đáng tại sao mã này nên biên dịch không

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

Điều này sẽ xuất

5.323: Did you expect Int?

Tôi tò mò nếu ai đó biết một cách để trình biên dịch ít nhất đưa ra một số cảnh báo với chữ ký được thực hiện của vai trò L.

ném một số cảnh báo với chữ ký thực hiện của vai trò L.

Bạn nhận được điều đó nếu bạn thêm tiền tố vào khai báo phương thức multi:

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

Với chương trình này, chương trình của bạn sẽ hiển thị:

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

Tôi muốn biết liệu có lý do chính đáng tại sao mã này sẽ biên dịch [mà không có multi]

Tôi nghĩ rằng mục đích thiết kế là để hỗ trợ hai khái niệm về thành phần đa hình:

• Nếu không có sựmulti , thi hành chỉ liên quan đến sự tồn tại của một phương pháp với quyền tên ; các tham số được bỏ qua.

• Với việcmulti thực thi bao gồm tên và tất cả các tham số ( hoặc một số ).

Cá nhân tôi đảm nhận liệu có lý do chính đáng cho:

• Hỗ trợ hai hương vị của đa hình phương pháp? Đôi khi thực thi tuân thủ nghiêm ngặt chữ ký là hữu ích. Đôi khi nó cản trở.

• Phân biệt chúng qua multi? Thực thi chữ ký đầy đủ yêu cầu các lớp / vai trò thực hiện có một phương thức với chính xác chữ ký đó. Nhưng điều gì sẽ xảy ra nếu một lớp / vai trò thực hiện muốn xử lý intthay vì Intcho một tham số? Raku thỏa hiệp. Được cung cấp một lớp / vai trò thực hiện có một phương thức tuân thủ chính xác, nó cũng có thể có các biến thể. Cách hoàn hảo để truyền đạt điều này là tiền tố một phương pháp sơ khai với multi.

• Có tên mặc định chỉ là đa hình? Chúng tôi có thể đã chọn multingữ nghĩa làm mặc định và người dùng sẽ viết onlytiền tố nếu họ chỉ muốn tên đa hình. Nhưng điều đó sẽ đảo ngược tình huống thông thường (tức là bỏ qua các phương pháp sơ khai). Tổng quát hơn, mục đích là Raku cung cấp một phạm vi nghiêm ngặt cho các tính năng của nó, từ thoải mái đến tăng tốc và chọn mặc định cho bất kỳ tính năng cụ thể nào được đánh giá đúng dựa trên phản hồi từ người dùng trong nhiều năm qua.

Điều gì xảy ra nếu mặc định có vẻ không đúng? Điều gì xảy ra nếu phạm vi nghiêm ngặt hiện tại không đủ? Điều gì xảy ra nếu một nhóm nghĩ rằng chúng ta nên đi bên trái và một nhóm khác nghĩ rằng chúng ta nên đi bên phải?

Raku có (imo) các cơ chế quản trị đáng chú ý để hỗ trợ sự phát triển ngôn ngữ do người dùng điều khiển. Ở cấp độ cao nhất có các yếu tố như kiến trúc bện . Ở cấp độ dưới cùng có các yếu tố như các loại phiên bản . Ở giữa là các yếu tố như RoleToClassApplierlàm trung gian cho quá trình áp dụng vai trò cho một lớp, đó là điểm mà tại đó một phương thức cần thiết phải được tìm thấy hoặc việc xây dựng lớp sẽ thất bại. Nói tóm lại, nếu ngôn ngữ không hoạt động theo cách bạn muốn, bao gồm cả những thứ như sự nghiêm ngặt, ít nhất về nguyên tắc, bạn có thể thay đổi ngôn ngữ đó.

Tôi giả sử ở đây bạn đang hỏi về lý do tại sao không có cảnh báo nào liên quan đến việc khai thác. Thật vậy, thông thường một phương pháp sơ khai phải được thực hiện - nhưng đó là phương pháp.

Bạn có thể thấy cách các vai trò được tạo thành lớp ở đây trong nguồn của Rakudo ( $yadavề cơ bản là $is-stubbed):

if $yada {
    unless has_method($!target, $name, 0)
            || $!target.HOW.has_public_attribute($!target, $name) {
        my @needed;
        for @!roles {
            for nqp::hllize($_.HOW.method_table($_)) -> $m {
                if $m.key eq $name {
                    nqp::push(@needed, $_.HOW.name($_));
                }
            }
        }
        nqp::push(@stubs, nqp::hash('name', $name, 'needed', @needed, 'target', $!target));
    }
}

Vì vậy, bạn có thể thấy rằng logic chỉ để xem liệu một phương thức có tồn tại cùng tên hay không. Chắc chắn có thể viết một mô-đun sẽ cập nhật logic này bằng cách tăng phương thức áp dụng () hoặc thay thế hoàn toàn RoleToClassApplierlớp. Tuy nhiên, nó có thể khó khăn. Ví dụ: xem xét:

class Letter { }
class A is Letter { } 
class B is Letter { }

role Foo {
  method foo (Letter) { ... }
}

class Bar does Foo { 
  method foo (A) { 'a' }
  method foo (B) { 'b' }
}

Chúng ta có nên xem xét phương pháp sơ khai để được thực hiện chính xác? Nhưng một người khác sau đó có thể nói class C is Lettervà đột nhiên nó không được thực hiện. (Tất nhiên, chúng ta có thể nói rằng logic tốt nhất sẽ được yêu cầu, ít nhất là, giống hệt hoặc siêu kiểu, nhưng điều đó gây khó chịu hơn mức cần thiết cho các ngôn ngữ động, IMO).

Không có, AFAICT, một phương thức được gọi là vai trò trong quá trình sáng tác cũng tham chiếu lớp (thực ra, không có phương thức nào được gọi cả add_method), vì vậy không có cách nào để viết séc của riêng bạn trong vai trò đó. (nhưng tôi có thể sai, có thể raiph, lizmat hoặc jnthn có thể sửa tôi).

Khuyến nghị của tôi trong trường hợp này là, thay vì khai thác nó, chỉ cần thêm vào một tuyên bố chết:

role L {
  method do-l(Int $a, Int $b --> Int) {
    die "SORRY! Classes implementing role L must support the signature (Int, Int)";
  }
}

Điều này sẽ không nắm bắt được nó trong quá trình biên dịch, nhưng nếu tại bất kỳ thời điểm nào, một phương thức khác Lcần phải gọi tới do-l(Int, Int)trêneveneven nếu lớp soạn thảo thực hiện các chữ ký khác, thì nó sẽ được gọi và lỗi được xử lý khá nhanh.