ทำไมตัวดำเนินการ Null-Safe (เช่น“ ตัวดำเนินการ Elvis”) ถูกปฏิเสธเนื่องจากเป็นส่วนหนึ่งของ“ Project Coin” ของ Java 7


10

หนึ่งในคุณสมบัติที่เสนอสำหรับ "Project Coin" ของ Java 7 คือ "โอเปอเรเตอร์ Elvis" รายงานนำเสนอ 2,009 JavaOneโครงการเหรียญอธิบายว่ามันเป็นเช่น:

หนึ่งใน "คุณสมบัติเล็ก ๆ " ที่กล่าวถึงในงานนำเสนอนี้คือสิ่งที่เรียกว่า "ผู้ดำเนินการ Elvis" ซึ่งเป็นผู้ประกอบการรุ่นที่สั้นกว่า ฉันพบว่าตัวเองขาดคุณสมบัติบางอย่างของ Groovy เมื่อใช้ Java แบบดั้งเดิมและนี่จะเป็นโอเปอเรเตอร์เดียวที่ฉันสามารถใช้ได้ทั้งสองภาษาหากมีการเพิ่มเข้ามา โอเปอเรเตอร์ "Elvis" มีประโยชน์สำหรับการระบุค่าเริ่มต้นที่สามารถใช้เมื่อนิพจน์ที่ประเมินเป็นโมฆะ เช่นเดียวกับโอเปอเรเตอร์ที่ปลอดภัยของ Groovy มันเป็นวิธีรัดกุมในการระบุวิธีหลีกเลี่ยงค่า null ที่ไม่จำเป็น ฉันบล็อกก่อนหน้านี้เกี่ยวกับวิธีที่ฉันต้องการหลีกเลี่ยง NullPointerException

ในขณะที่แง่มุมอื่น ๆ ของ Project Coin ถูกนำไปใช้ในท้ายที่สุด เหตุใด Elvis Operator จึงปฏิเสธในที่สุดแม้ว่าจะถูกนำเสนอที่ JavaOne ในฐานะผู้สมัครที่น่าจะได้รับการคัดเลือก

เพื่อความชัดเจนฉันถามเฉพาะผู้ดำเนินการนี้และเหตุผลที่ถูกปฏิเสธเนื่องจากเป็นส่วนหนึ่งของ "Project Coin" ของ Java 7 เนื่องจากพิจารณาอย่างจริงจังแล้ว ฉันสงสัยว่ามีรายการส่งจดหมายหรือเหตุผลที่ปฏิเสธไม่ได้พูดคุยกัน แต่ฉันไม่พบสิ่งใด หากมีข้อมูลทั่วไปเพิ่มเติมเกี่ยวกับสาเหตุที่ไม่รวมอยู่ใน Java เวอร์ชันใด ๆ ที่ยอมรับได้ แต่ไม่ต้องการ


4
จิตใจที่น่าสงสัย?
Ewan

1
อาจเป็นไปได้เพราะมันสนับสนุนและสนับสนุนให้ใช้ค่า Null เป็นค่าที่ถูกต้องและเป็นพื้นฐานที่ตรงกันข้ามกับหลักการ OO เพราะคุณตรวจสอบประเภทของวัตถุก่อนที่จะดำเนินการวิธีการ
JacquesB

หากไม่มีใครขุดเอกสารที่ชัดเจน (อีเมลบันทึกช่วยจำ) ของกระบวนการตัดสินใจหรือเป็นผู้มีส่วนร่วมโดยตรงในการตัดสินใจเราไม่สามารถรู้คำตอบได้ที่นี่จริงๆ เช่นคำตอบของ Robert เป็นเพียงการคาดเดาและการพิจารณาการออกแบบภาษาทั่วไปไม่ใช่เหตุผลที่เป็นข้อเท็จจริงและเฉพาะเจาะจงสำหรับการปฏิเสธผู้ปฏิบัติงานนี้ ฉันจึงลงคะแนนให้ปิดคำถามนี้ตามความคิดเห็น
amon

1
@ มอน: ฉันยอมรับอย่างอิสระว่าคำตอบของฉันคือการเก็งกำไรในตอนต้นของโพสต์ อย่างไรก็ตามฉันโพสต์คำตอบต่อไปเพราะ 1. ฉันสอนวิธีการตกปลาแทนที่จะให้ปลาและ 2. โพสต์นี้สามารถใช้เป็นเป้าหมายสำหรับการหลอกแบบปิดหากเราเล่นไพ่ของเราถูกต้อง แนวคิดที่อยู่เบื้องหลังคำตอบที่ให้การวิเคราะห์โดยทั่วไปคือไม่สนับสนุนการโต้แย้งที่ไม่สิ้นสุดเกี่ยวกับการตัดสินใจทางภาษาและช่วยให้ผู้อื่นเห็นภาพรวมของปัญหาโดยรวมที่กว้างขึ้น
Robert Harvey

@RobertHarvey A "ทำไมภาษา X ไม่มีฟีเจอร์ Y" ซึ่งเป็นเป้าหมายแบบดัลลัสของแคนนอนจะสะดวก แต่คำถามในรูปแบบปัจจุบันดูเหมือนจะไม่เหมาะสำหรับคำถามนั้น หากต้องแก้ไขเพื่อถามคำถามทั่วไปนี้ (ใช้ X = Java / Y = ?.เป็นตัวอย่าง ) แน่นอนว่ามันจะกว้างเกินไปสำหรับคำถามทั่วไป แต่คุณจะได้คำตอบที่ดี
amon

คำตอบ:


15

บุคคลที่ดีที่สุดที่จะถามคำถามนี้คือคนในคณะกรรมการบริหารของ JCPไม่ใช่พวกเรา อย่างไรก็ตามนั่นจะไม่ป้องกันฉันจากการมีส่วนร่วมในการเก็งกำไรว่าง

คำตอบของคำถามที่ว่า "ทำไมคุณลักษณะนี้จึงไม่ได้ถูกนำไปใช้" ทุกครั้งเป็นเพราะผลประโยชน์ไม่เกินต้นทุน

Eric Lippert (อดีตสมาชิกของทีม C #) กล่าวว่าเพื่อให้ผลิตภัณฑ์มีคุณลักษณะคุณลักษณะนั้นต้องเป็น:

  • คิดในตอนแรก
  • ต้องการ
  • ได้รับการออกแบบ
  • ที่ระบุ
  • การดำเนินการ
  • การทดสอบ
  • เอกสาร
  • ส่งให้กับลูกค้า

กล่าวอีกนัยหนึ่งจะต้องมีสิ่งสำคัญหลายอย่างที่จะต้องเกิดขึ้นก่อนที่จะสามารถรับรู้คุณลักษณะของภาษาโปรแกรมใหม่ได้ ค่าใช้จ่ายมีขนาดใหญ่กว่าที่คุณคิด

ในทีม C # ทุกคำขอคุณลักษณะใหม่จะเริ่มต้นด้วยคะแนนลบ 100 จากนั้นทีมจะประเมินผลประโยชน์และค่าใช้จ่ายการเพิ่มคะแนนเพื่อประโยชน์และการลบคะแนนสำหรับค่าใช้จ่าย หากคะแนนไม่เกินศูนย์คุณลักษณะที่เสนอจะถูกยกเลิกโดยสรุป กล่าวอีกนัยหนึ่งคุณลักษณะใหม่จะต้องให้ประโยชน์ที่น่าสนใจ

แต่ตัวดำเนินการ Elvisทำให้มันกลายเป็น C # แล้วทำไมมันไม่ทำให้เป็น Java?

แม้จะมีความคล้ายคลึงกันอย่างชัดเจนJava และ C # มีปรัชญาภาษาที่แตกต่างกันอย่างมีนัยสำคัญ สิ่งนี้พิสูจน์ได้จากความจริงที่ว่าโปรแกรมระดับองค์กรของ Java มีแนวโน้มที่จะมีขนาดใหญ่และมีโครงสร้างชุดของสถาปัตยกรรม ความกะทัดรัดและการแสดงออกทางภาษานั้นเสียสละบนแท่นบูชาของพิธีและความง่ายในการเขียนโค้ด รูปแบบสถาปัตยกรรมซอฟต์แวร์ที่รู้จักกันดีซึ่งทุกคนในทีมพัฒนาสามารถรับรู้ได้นั้นเป็นที่ต้องการมากกว่าความสะดวกด้านภาษา

พิจารณาการแลกเปลี่ยน Reddit นี้ :

ตัวดำเนินการ Elvis ได้รับการเสนอสำหรับ Java ทุกรุ่นตั้งแต่ 7 และถูกปฏิเสธทุกครั้ง ภาษาที่แตกต่างกันตกอยู่ในจุดที่แตกต่างกันตามสเปกตรัมจาก "บริสุทธิ์" ถึง "ในทางปฏิบัติ" และภาษาที่ใช้งานผู้ดำเนินการ Elvis นั้นมีแนวโน้มที่จะไปสู่จุดสิ้นสุดของสเปกตรัมมากกว่า Java

หากคุณมีทีมงานผู้เชี่ยวชาญด้าน Java มากกว่า 15 ปีที่เขียนระบบการประมวลผลแบ็กเอนด์ที่กระจายกันอย่างมากพร้อมกันในบางประเภทคุณอาจต้องการสถาปัตยกรรมที่เข้มงวดมากขึ้น

อย่างไรก็ตามหากคุณมีทีมระดับต้นถึงระดับกลางครึ่งหนึ่งย้ายจาก Visual Basic และคุณให้พวกเขาเขียนแอปเว็บ ASP.NET ที่ส่วนใหญ่จะใช้งาน CRUD ในการดำเนินการ ... อาจเป็นเพราะ overkill ในการออกแบบเครือ ของAbstractFactoryFactoryคลาสที่แยกออกจากข้อเท็จจริงที่ว่าคุณไม่สามารถควบคุมได้ว่าคอลัมน์ใดเป็นโมฆะในฐานข้อมูลดั้งเดิมที่คุณต้องใช้

ความแตกต่างที่ลึกซึ้งในปรัชญาภาษานี้ไม่เพียงขยายไปถึงวิธีการใช้ภาษาเท่านั้น แต่ยังรวมถึงวิธีการออกแบบภาษาด้วยตนเอง C # เป็นภาษาเผด็จการใจดี ที่จะได้รับคุณสมบัติใหม่ที่เป็น C # คุณเท่านั้นจริงๆต้องโน้มน้าวให้คนคนหนึ่ง: Anders Hejlsberg

Java ใช้แนวทางอนุรักษ์นิยมมากกว่า เพื่อให้ได้คุณสมบัติใหม่ใน Java นั้นจะต้องได้รับฉันทามติจากกลุ่มผู้ค้ารายใหญ่เช่น Oracle, IBM, HP, Fujitsu และ Red Hat เห็นได้ชัดว่ากระบวนการนั้นจะช้าลงและนำเสนอแถบที่สูงขึ้นสำหรับคุณสมบัติภาษาใหม่

คำถาม "ทำไมฟีเจอร์ x ถึงไม่ได้ใช้งาน ... " รวมคำเหล่านั้นไว้โดยปริยายเสมอ "... ถ้าเห็นได้ชัดว่าเป็นความคิดที่ดี?" ตามที่ฉันได้แสดงให้เห็นอย่างเพียงพอที่นี่ตัวเลือกไม่เคยง่ายขนาดนั้น


8
sarcasm: เนื่องจากคลาส AbstractFactoryFactory เป็นตัวบ่งชี้ที่ดีของความเข้มงวดด้านสถาปัตยกรรมและไม่ใช่การเขียนโค้ด / ถากถาง
Machado

2
@RobertHarvey ข้อสรุปของคุณเกี่ยวกับบทบาทของคณะกรรมการในการออกแบบภาษาจาวานั้นง่ายเกินไป ในขณะที่มีการทำงานร่วมกันกับชุมชนและกับพันธมิตรในอุตสาหกรรมข้อความว่าภาษาจาวาคือ "การออกแบบโดยคณะกรรมการ" นั้นค่อนข้างไม่ถูกต้องสมบูรณ์และคำอธิบายที่แย่มาก (แม้ว่าจะน่าเศร้าและน่าเชื่อมาก) สำหรับคำถามของโปสเตอร์นี้
Brian Goetz

5
เหตุผลก่อนหน้านี้ส่วนใหญ่ที่คุณแสดงไว้ - คุณลักษณะภาษาทุกภาษามีขนาดใหญ่กว่าที่ทุกคนคิดว่างบประมาณ จำกัด (สำหรับความพยายามในการเปลี่ยนแปลงเพื่อความซับซ้อน) - ถูกต้อง และฉันจะเพิ่ม: เราไม่ได้ทำคุณสมบัติ X เพราะเราคิดว่าคุณสมบัติอื่น ๆ Y และ Z เป็นตัวเลือกที่ดีกว่า นอกจากนี้เรายังใช้แนวทางอนุรักษ์นิยมมากกว่าภาษาอื่น ๆ เนื่องจากเรารู้ว่าคุณลักษณะแต่ละอย่างมีปฏิสัมพันธ์หรือในบางกรณีมีการบังคับใช้คุณสมบัติที่เป็นไปได้อื่น ๆ ในอนาคต เราต้องการให้ Java ยังคงมีชีวิตชีวาและมีความเกี่ยวข้องใน 20 ปีซึ่งหมายความว่าไม่จำเป็นต้องยัดเยียดในทุก ๆ คุณสมบัติที่อาจดูเท่
Brian Goetz

1
@BrianGoetz: เนื่องจากปัญหาดูเหมือนจะเป็นลักษณะที่ดูถูกของคำว่า "ออกแบบโดยคณะกรรมการ" (คุณจะทราบว่าฉันไม่ได้ดูหมิ่น Java ด้วยวิธีอื่น) ฉันจึงเปลี่ยนคำตอบเล็กน้อยเพื่อลบคำนั้นออก
Robert Harvey

1
เคยมีการแข่งขันระหว่างนักออกแบบ C # และ Java C # ถูกพิจารณาว่าเป็นสิ่งที่ฉีกขาดโดยนักออกแบบ Java ผู้ได้รับมอบหมาย C # ถูกปฏิเสธเนื่องจากเป็น "ไม่ใช่เชิงวัตถุ" แต่เหตุผลที่แท้จริงคือเพราะพวกเขาปรากฏตัวใน C # ก่อน มันเป็นเรื่องดีที่จะคิดว่ามันเป็นเพียงเหตุผลเหตุผลที่คุณสมบัติบางอย่างถูกเพิ่มหรือปล่อยออก ... ฉันสงสัย
Frank Hileman
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.