Tại sao các biểu thức lambda không "interned"?

Question

Chuỗi là các loại tham chiếu, nhưng chúng không thay đổi. Điều này cho phép chúng được interned bởi trình biên dịch; ở khắp mọi nơi cùng một chuỗi chữ xuất hiện, cùng một đối tượng có thể được tham chiếu.

Đại biểu cũng là loại tham chiếu không thay đổi. (Thêm một phương thức cho một đại biểu multicast bằng cách sử dụng toán tử += cấu thành gán; đó không phải là khả năng biến đổi.) Và, giống như, chuỗi, có một cách "theo nghĩa đen" để đại diện cho một đại biểu trong mã, sử dụng một biểu thức lambda, ví dụ:

Func<int> func =() => 5; 

Phía bên phải của tuyên bố đó là biểu thức có loại Func<int>; nhưng không nơi nào tôi gọi một cách rõ ràng các nhà xây dựng Func<int> (cũng không phải là một chuyển đổi tiềm ẩn xảy ra). Vì vậy, tôi xem chủ đề này thực chất là chữ số. Tôi có nhầm lẫn về định nghĩa của tôi về "chữ" ở đây không?

Bất kể, đây là câu hỏi của tôi. Nếu tôi có hai biến cho, nói rằng, các loại Func<int>, và tôi gán biểu thức lambda giống hệt nhau cho cả hai:

Func<int> x =() => 5; 
Func<int> y =() => 5; 

... gì đang ngăn cản các trình biên dịch từ điều trị này như là cùng một đối tượng Func<int>?

Tôi hỏi vì mục 6.5.1 của C# 4.0 language specification nêu rõ:

Chuyển đổi của ngữ nghĩa giống hệt chức năng ẩn danh với cùng (có thể rỗng) bộ ngoài trường biến bị bắt với cùng đại biểu các loại được phép (nhưng không được yêu cầu ) để trả lại cùng một cá nhân đại diện . Thuật ngữ ngữ nghĩa giống hệt nhau được sử dụng ở đây để ngụ ý rằng thực hiện các hàm ẩn danh sẽ, trong mọi trường hợp, tạo ra cùng một hiệu ứng cho cùng một đối số.

Điều này làm tôi ngạc nhiên khi đọc; nếu hành vi này rõ ràng là cho phép, tôi đã mong đợi nó sẽ được triển khai. Nhưng có vẻ như không. Điều này trong thực tế đã nhận được rất nhiều nhà phát triển gặp rắc rối, đặc biệt. khi các biểu thức lambda đã được sử dụng để gắn các trình xử lý sự kiện thành công mà không có khả năng loại bỏ chúng. Ví dụ:

class EventSender 
{ 
    public event EventHandler Event; 
    public void Send() 
    { 
     EventHandler handler = this.Event; 
     if (handler != null) { handler(this, EventArgs.Empty); } 
    } 
} 

class Program 
{ 
    static string _message = "Hello, world!"; 

    static void Main() 
    { 
     var sender = new EventSender(); 
     sender.Event += (obj, args) => Console.WriteLine(_message); 
     sender.Send(); 

     // Unless I'm mistaken, this lambda expression is semantically identical 
     // to the one above. However, the handler is not removed, indicating 
     // that a different delegate instance is constructed. 
     sender.Event -= (obj, args) => Console.WriteLine(_message); 

     // This prints "Hello, world!" again. 
     sender.Send(); 
    } 
} 

Có bất kỳ lý do tại sao điều này vi-một thể hiện ủy nhiệm cho anonymous ngữ nghĩa giống hệt phương pháp-không được thực hiện?

Answer 1

Bạn nhầm là gọi nó là IMO theo nghĩa đen. Nó chỉ là một biểu thức có thể chuyển đổi thành kiểu đại biểu.

Bây giờ là phần "interning" - một số biểu thức lambda là được lưu trong bộ nhớ cache, đôi khi một cá thể đơn lẻ có thể được tạo và sử dụng lại. Một số không được xử lý theo cách đó: nó thường phụ thuộc vào việc biểu thức lambda nắm bắt bất kỳ biến không tĩnh (cho dù đó là thông qua "này" hoặc địa phương để phương pháp).

Dưới đây là một ví dụ về bộ nhớ đệm này:

using System; 

class Program 
{ 
    static void Main() 
    { 
     Action first = GetFirstAction(); 
     first -= GetFirstAction(); 
     Console.WriteLine(first == null); // Prints True 

     Action second = GetSecondAction(); 
     second -= GetSecondAction(); 
     Console.WriteLine(second == null); // Prints False 
    } 

    static Action GetFirstAction() 
    { 
     return() => Console.WriteLine("First"); 
    } 

    static Action GetSecondAction() 
    { 
     int i = 0; 
     return() => Console.WriteLine("Second " + i); 
    } 
} 

Trong trường hợp này chúng ta có thể thấy rằng các hành động đầu tiên được lưu trữ (hoặc ít nhất, hai bằng đại biểu được sản xuất, và trong thực tế Reflector cho thấy rằng nó thực sự là được lưu trong một trường tĩnh). Hành động thứ hai đã tạo hai trường hợp không bằng nhau là Action cho hai cuộc gọi đến GetSecondAction, đó là lý do tại sao "giây" không phải là vô giá trị ở cuối.

Các lambda nội bộ xuất hiện ở các vị trí khác nhau trong mã nhưng với cùng một mã nguồn là một vấn đề khác. Tôi nghi ngờ nó sẽ là khá phức tạp để làm điều này đúng (sau khi tất cả, cùng một mã nguồn có thể có nghĩa là những thứ khác nhau ở những nơi khác nhau) và tôi chắc chắn sẽ không muốn dựa trên nó diễn ra. Nếu nó không đáng để dựa vào, và có rất nhiều việc phải làm cho nhóm biên dịch, tôi không nghĩ đó là cách tốt nhất mà họ có thể dành thời gian của họ.

Answer 2

Không thể thực tập lambdas vì chúng sử dụng đối tượng để chứa các biến cục bộ đã chụp. Và trường hợp này là khác nhau mỗi khi bạn xây dựng các đại biểu.

Answer 3

Nói chung, không có sự khác biệt giữa các biến chuỗi tham chiếu đến cùng một cá thể String, so với hai biến tham chiếu đến các chuỗi khác nhau có chứa cùng một chuỗi ký tự. Điều này cũng không đúng đối với các đại biểu.

Giả sử tôi có hai đại biểu, được gán cho hai biểu thức lambda khác nhau. Sau đó tôi đăng ký cả hai đại biểu để xử lý sự kiện và hủy đăng ký. Kết quả là gì? Nó có thể hữu ích nếu có một cách trong vb hoặc C# để chỉ định rằng một phương thức nặc danh hoặc lambda không tham chiếu đến Me/điều này nên được coi là phương pháp tĩnh, tạo ra một đại biểu duy nhất có thể được tái sử dụng trong suốt cuộc đời của ứng dụng. Không có cú pháp để chỉ ra rằng, tuy nhiên, và để trình biên dịch quyết định có các biểu thức lambda khác nhau trả về cùng một cá thể sẽ là một thay đổi có khả năng phá vỡ.

EDIT Tôi đoán đặc tả cho phép nó, mặc dù nó có thể là một thay đổi có khả năng phá vỡ nếu bất kỳ mã nào dựa vào các cá thể khác biệt.

Answer 4

Các câu trả lời khác mang lại những điểm tốt. Tôi thực sự không phải làm bất cứ điều gì kỹ thuật - Every feature starts out with -100 points.

Answer 5

Điều này được cho phép vì nhóm C# không thể kiểm soát điều này. Họ phụ thuộc rất nhiều vào các chi tiết thực hiện của các đại biểu (CLR + BCL) và trình tối ưu hóa trình biên dịch JIT. Hiện đã có khá một sự gia tăng của CLR và jitter triển khai ngay bây giờ và có rất ít lý do để giả định đó sẽ kết thúc. Đặc tả CLI rất nhẹ về các quy tắc về các đại biểu, không đủ mạnh để đảm bảo tất cả các nhóm khác nhau này sẽ kết thúc với việc triển khai đảm bảo rằng bình đẳng đối tượng đại biểu là nhất quán. Không ít nhất là vì điều đó sẽ cản trở sự đổi mới trong tương lai. Có rất nhiều thứ để tối ưu hóa ở đây.

Answer 6

Có bất kỳ lý do nào tại sao hành vi này — một cá thể ủy nhiệm cho các phương thức vô danh giống hệt hệt nhau không được triển khai?

Có.Bởi vì dành thời gian vào một tối ưu hóa khôn lanh mà hầu như không ai mất thời gian để thiết kế, triển khai, thử nghiệm và duy trì các tính năng mà làm mang lại lợi ích cho mọi người.