Tại sao các toán tử Null-Safe (ví dụ: Toán tử Elvis Toán tử) bị từ chối như là một phần của Dự án Coin Coin của Java 7?


10

Một trong những tính năng được đề xuất cho "Project Coin" của Java 7 là "Toán tử Elvis". Một báo cáo về bài thuyết trình JavaOne năm 2009 trên Project Coin đã mô tả nó như sau:

Một trong những "tính năng nhỏ" được trình bày trong bài trình bày này là cái gọi là "toán tử Elvis", một phiên bản ngắn gọn hơn của toán tử ternary. Tôi thấy mình thiếu một số tính năng của Groovy khi sử dụng Java truyền thống và đây sẽ là một toán tử mà tôi có thể sử dụng bằng cả hai ngôn ngữ nếu được thêm vào. Toán tử "Elvis" thuận tiện cho việc chỉ định giá trị mặc định có thể được sử dụng khi biểu thức được đánh giá là null. Giống như toán tử điều hướng an toàn của Groovy, đây là một cách ngắn gọn để chỉ định cách tránh các null không cần thiết. Tôi đã viết blog trước đây về cách tôi muốn tránh NullPulumException.

Mặc dù các khía cạnh khác của Project Coin cuối cùng đã được triển khai, nhưng khía cạnh này thì không. Tại sao Nhà điều hành Elvis cuối cùng bị từ chối, mặc dù được trình bày tại JavaOne như một ứng cử viên có khả năng đưa vào?

Để rõ ràng, tôi đặc biệt hỏi về toán tử này và lý do nó bị từ chối như là một phần của "Project Coin" của Java 7, cho rằng nó đã được xem xét nghiêm túc sau đó. Tôi nghi ngờ rằng có những danh sách gửi thư hoặc những lý do từ chối nó đã được thảo luận, nhưng tôi không thể tìm thấy bất cứ điều gì. Nếu có thông tin chung hơn về lý do tại sao nó không được bao gồm trong bất kỳ phiên bản Java nào, điều đó có thể chấp nhận nhưng không được ưa thích.


4
tâm trí đáng ngờ?
Ewan

1
Có khả năng vì nó hỗ trợ và khuyến khích việc sử dụng null làm giá trị hợp pháp và về cơ bản hơn là phản đối các nguyên tắc OO vì bạn kiểm tra loại đối tượng trước khi thực hiện phương thức.
JacquesB

Trừ khi ai đó sẽ đào các tài liệu rõ ràng (email, ghi nhớ, bảng điểm) của quá trình ra quyết định hoặc là người trực tiếp tham gia quyết định, chúng tôi thực sự không thể biết câu trả lời ở đây. Ví dụ, câu trả lời của Robert chỉ là suy đoán và cân nhắc thiết kế ngôn ngữ chung, không phải là lý do thực tế và cụ thể cho việc từ chối nhà điều hành này. Do đó, tôi đang bỏ phiếu để đóng câu hỏi này dưới dạng ý kiến.
amon

1
@amon: Tôi tự do thừa nhận rằng câu trả lời của tôi là suy đoán ở đầu bài viết của tôi. Tuy nhiên, dù sao tôi cũng đã đăng câu trả lời vì 1. Tôi đang dạy cách câu cá thay vì cho một con cá và 2. Bài này có thể được sử dụng làm mục tiêu cho những kẻ lừa đảo gần gũi, nếu chúng ta chơi bài đúng cách. Ý tưởng đằng sau một câu trả lời cung cấp một phân tích chung là không khuyến khích những tranh luận bất tận về các quyết định ngôn ngữ phút và giúp người khác nhìn thấy một cái nhìn rộng hơn về các vấn đề tổng thể.
Robert Harvey

@RobertHarvey A Kiếm Tại sao ngôn ngữ X không có tính năng mục tiêu chính quy Y Y sẽ thuận tiện, nhưng câu hỏi ở dạng hiện tại của nó có vẻ không phù hợp với điều đó. Nếu nó được chỉnh sửa để đặt câu hỏi chung này (sử dụng X = Java / Y = ?.làm ví dụ ) thì chắc chắn nó sẽ quá rộng như một câu hỏi thông thường, nhưng bạn sẽ có một câu trả lời hay.
amon

Câu trả lời:


15

Đương nhiên, người tốt nhất để hỏi câu hỏi này là một người trong Ban chấp hành JCP, không phải chúng tôi. Tuy nhiên, điều đó sẽ không ngăn cản tôi tham gia vào một số suy đoán nhàn rỗi.

Câu trả lời cho mọi câu hỏi "tại sao tính năng này không được triển khai" luôn là vì lợi ích không vượt quá chi phí.

Eric Lippert (cựu thành viên của nhóm C #) nói rằng, để sản phẩm có một tính năng, tính năng đó phải là:

  • nghĩ đến ngay từ đầu
  • mong muốn
  • được thiết kế
  • được chỉ định
  • thực hiện
  • thử nghiệm
  • tài liệu
  • vận chuyển đến khách hàng

Nói cách khác, phải có nhiều điều quan trọng phải xảy ra trước khi bất kỳ tính năng ngôn ngữ lập trình mới nào có thể được nhận ra. Các chi phí lớn hơn bạn nghĩ.

Trong nhóm C #, mọi yêu cầu tính năng mới bắt đầu với số điểm trừ 100. Sau đó, nhóm đánh giá lợi ích và chi phí, thêm điểm cho lợi ích và trừ điểm cho chi phí. Nếu điểm không vượt quá 0, tính năng được đề xuất sẽ bị loại bỏ. Nói cách khác, tính năng mới phải cung cấp một lợi ích hấp dẫn.

Nhưng Toán tử Elvis đã biến nó thành C #. Vậy tại sao nó không biến nó thành Java?

Mặc dù có sự tương đồng rõ ràng, Java và C # có những triết lý ngôn ngữ khác nhau đáng kể. Điều này được chứng minh bằng thực tế là các chương trình doanh nghiệp Java có xu hướng lớn, các bộ sưu tập kiến ​​trúc có cấu trúc. Lực hấp dẫn và biểu cảm ngôn ngữ được hy sinh trên bàn thờ và dễ mã hóa. Các mẫu kiến ​​trúc phần mềm nổi tiếng mà mọi người trong nhóm phát triển có thể nhận ra được ưa thích hơn các tiện ích ngôn ngữ.

Hãy xem xét trao đổi Reddit này :

Toán tử Elvis đã được đề xuất cho mọi phiên bản Java kể từ 7 và đã bị từ chối mỗi lần. Các ngôn ngữ khác nhau rơi vào các điểm khác nhau dọc theo phổ từ "thuần túy" đến "thực dụng" và các ngôn ngữ triển khai toán tử Elvis có xu hướng tiến xa hơn về phía cuối thực dụng của phổ so với Java.

Nếu bạn có một nhóm hơn 15 năm Java viết một hệ thống xử lý phụ trợ phân tán cao, đồng thời cao, thì có lẽ bạn muốn có một mức độ nghiêm ngặt về kiến ​​trúc.

Tuy nhiên, nếu bạn có một nhóm từ trung cấp đến trung cấp, một nửa trong số họ đã di chuyển từ Visual Basic và bạn có họ viết một ứng dụng web ASP.NET mà hầu hết chỉ thực hiện các thao tác CRUD ... thì có thể sẽ quá mức để thiết kế một bó của AbstractFactoryFactorycác lớp để trừu tượng hóa thực tế là bạn không có quyền kiểm soát cột nào là không thể trong cơ sở dữ liệu kế thừa shitty mà bạn phải sử dụng.

Những khác biệt sâu sắc trong triết học ngôn ngữ không chỉ mở rộng đến cách sử dụng ngôn ngữ, mà còn cả cách thức mà quá trình thiết kế ngôn ngữ được thực hiện. C # là một ngôn ngữ độc tài nhân từ . Để có được một tính năng mới vào C #, bạn chỉ thực sự phải thuyết phục một người: Anders Hejlsberg .

Java có một cách tiếp cận bảo thủ hơn. Để có được một tính năng mới vào Java, nó phải nhận được sự đồng thuận từ một tập đoàn gồm các nhà cung cấp lớn như Oracle, IBM, HP, Fujitsu & Red Hat. Rõ ràng, quá trình đó sẽ chậm hơn và đưa ra một thanh cao hơn cho các tính năng ngôn ngữ mới.

Câu hỏi "tại sao tính năng x không được triển khai ..." luôn luôn bao gồm các từ, "... nếu đó rõ ràng là một ý tưởng tốt?" Như tôi đã chứng minh đầy đủ ở đây, sự lựa chọn không bao giờ đơn giản.


8
mỉa mai: Bởi vì các lớp AbstractFactoryFactory là một chỉ số tốt về sự nghiêm ngặt của kiến ​​trúc, và không phải là mã đầy đủ. /mỉa mai.
Machado

2
@RobertHarvey Kết luận của bạn về vai trò của các ủy ban trong việc thiết kế ngôn ngữ Java là quá đơn giản. Mặc dù thực sự có sự cộng tác với cộng đồng và với các đối tác trong ngành, nhưng tuyên bố rằng ngôn ngữ Java là "thiết kế theo ủy ban" hoàn toàn không chính xác và là một lời giải thích khủng khiếp (mặc dù đáng buồn, cực kỳ đáng tin) cho câu hỏi của người đăng bài này.
Brian Goetz

5
Hầu hết các lý do trước đây bạn liệt kê - mọi tính năng ngôn ngữ đều lớn hơn mọi người nghĩ, ngân sách hữu hạn (cho nỗ lực, thay đổi, vì sự phức tạp) - là chính xác. Và tôi thêm: chúng tôi không làm tính năng X vì chúng tôi nghĩ rằng các tính năng khác Y và Z là lựa chọn tốt hơn. Hơn nữa, chúng tôi cũng có một cách tiếp cận bảo thủ hơn các ngôn ngữ khác, vì chúng tôi biết mỗi tính năng tương tác với hoặc trong một số trường hợp bị tịch thu, các tính năng có thể khác trong tương lai. Chúng tôi muốn Java duy trì sự sôi động và có liên quan trong 20 năm, điều đó có nghĩa là không nhất thiết phải nhồi nhét mọi tính năng có vẻ hay.
Brian Goetz

1
@BrianGoetz: Vì vấn đề có vẻ là bản chất của thuật ngữ "thiết kế theo ủy ban" (bạn sẽ lưu ý rằng tôi đã không chê bai Java theo bất kỳ cách nào khác), tôi đã thay đổi câu trả lời của mình một chút để loại bỏ thuật ngữ này.
Robert Harvey

1
Đã từng có một số sự cạnh tranh giữa các nhà thiết kế C # và Java. C # được coi là sự lột xác của các nhà thiết kế Java (và đúng như vậy). Các đại biểu C # đã bị từ chối vì "không hướng đối tượng", nhưng lý do thực sự là vì họ xuất hiện trong C # trước tiên. Thật tuyệt khi nghĩ rằng chỉ vì lý do hợp lý mà một số tính năng được thêm hoặc bỏ qua ... Tôi nghi ngờ điều đó.
Frank Hileman
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.