2012-08-26 28 views
5

thể trùng lặp:
Generic methods and method overloadingTại sao sự mơ hồ với generics không phù hợp, thay vì tăng lỗi?

Nói rằng tôi có một lớp học như

class SortedList<K> 
{ 
    public string this[int i] { get { return "a"; /* dummy sample code */ } } 
    public string this[K key] { get { return "b"; /* dummy sample code */ } } 
} 

Bây giờ chúng ta hãy nói một số anh chàng quyết định sử dụng nó:

static string Test1<K>(K key) { return new SortedList<K>()[key]; } 

Trình biên dịch giải quyết cuộc gọi này đến quá tải K key.

Bây giờ, độ tương phản này với nói

static string Test2(int key) { return new SortedList<int>()[key]; } // whoops 

nơi trình biên dịch này để giải quyết các int i quá tải.

Bây giờ nếu một số linh hồn tội nghiệp nói Test1(0), anh ta sẽ nhận được kết quả khác sau đó nếu anh ta nói Test2(0), mặc dù cơ thể trông khá giống hệt nhau ở cái nhìn đầu tiên.

Điều thú vị hơn là, trong mọi trường hợp, trình biên dịch hoặc thời gian chạy không phát hiện được sự mơ hồ và đưa ra lỗi.
Thay vào đó, thời gian chạy chỉ thay đổi hành vi của nó liên quan đến việc liệu giá trị có phải là chung hay không, điều này có thể rõ ràng bất ngờ cho người gọi.

Tại sao là hành vi không phù hợp?
Hoặc, tốt hơn, tại sao không có lỗi trình biên dịch (hoặc thời gian chạy) vì sự mơ hồ?

+0

@SergRogovtsev: Wow, đẹp quá! Không thấy cái đó; dường như trả lời điều này một cách hoàn hảo.Chúng ta nên bỏ phiếu để đóng câu hỏi của tôi sau đó. – Mehrdad

Trả lời

0

tại sao bạn nghĩ suy nghĩ đó là hành vi không phù hợp? nó chỉ là điểm, bạn PHẢI TRÊN chỉ mục-getter với một "có thể-key" -type getter ...

bạn nghĩ gì, nên là kết quả mong đợi? một lời cảnh báo? đó là nhu cầu của nhà phát triển để kiểm tra những loại bạn muốn sử dụng cho generics nào ... nó đủ thông minh để kiểm tra, rằng phương pháp "test1" sẽ giải quyết getter dựa trên khóa và test2 chỉ getter dựa trên chỉ mục ...

bạn phải không cho phép "int" làm loại (ví dụ như ràng buộc theo lớp) hoặc triển khai phương thức getter khác ở đây ...

0

Vì trình biên dịch không gọi ra cảnh báo hoặc lỗi về những thứ nó nghi ngờ có thể xuất hiện mơ hồ với bạn. Nó gọi ra những thứ mà nó thấy là mơ hồ. Nhưng không có gì mơ hồ với trình biên dịch ở đây.

Giả sử tôi đưa cho bạn hình vuông và hình chữ nhật và yêu cầu bạn đặt các ô vuông vào đống a và hình chữ nhật thành đống b. Hơn nữa, bạn không cần phải nhìn vào các đối tượng để xem chúng là hình vuông hay hình chữ nhật vì chúng đã được dán nhãn như vậy. Bây giờ ... tại một số điểm, tôi đưa cho bạn một đối tượng được đánh dấu là hình chữ nhật nhưng bạn nhận thấy rằng nó cũng là một hình vuông. Bây giờ, tôi đã không nói với bạn để phân tích các đối tượng ... Tôi đã nói với bạn chỉ cần làm theo hướng dẫn và tổ chức chúng theo cách tôi dán nhãn chúng. Và đó là cách trình biên dịch hoạt động ... thực hiện chính xác những gì bạn bảo nó làm.

+0

Chắc chắn, nhưng thời gian chạy có thể gây ra lỗi không? Nó sẽ có vẻ tốt hơn so với hành vi không nhất quán. – Mehrdad

+0

Nhiều người kết luận lập luận (bằng nhiều từ) rằng thực tế là trình biên dịch thực hiện điều gì đó theo một cách nhất định phải có nghĩa là nó đúng. Tôi thường không đồng ý với logic đó. Tuy nhiên trường hợp này là khác nhau bởi vì bạn nói rằng hành vi này là không nhất quán, nhưng đồng thời bạn chỉ ra rằng nó * IS * nhất quán khi bạn nói nó chọn dựa trên liệu giá trị có phải là chung hay không. Vậy ai thực sự không nhất quán ở đây? : p –

+0

Huh? Generics cho hành vi khác nhau từ phi generics, mặc dù các loại thay thế là như nhau. Tôi gọi đó là không nhất quán. – Mehrdad

Các vấn đề liên quan