เหตุใดภาษาการเขียนโปรแกรมจึงสร้างลายเซ็นของเมธอดโดยไม่เกี่ยวข้องกับชนิดส่งคืน


11

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

อัปเดต: ฉันหมายถึงภาษาที่รวบรวมโดยสแตติกพิมพ์


นี่คือการคาดเดาที่ไม่มีมูลความจริงมาก แต่ฉันคิดว่ามันมีบางอย่างเกี่ยวกับความยากลำบากในการใช้งานคอมไพเลอร์และ / หรือการสนับสนุนเครื่องมือ
Charles Lambert

ใน Haskell คุณสามารถใช้ typeclasses ในการสร้างฟังก์ชั่นที่ขึ้นอยู่กับชนิดของการส่งคืน ฉัน <3 Haskell: D: D: D
Thomas Eding

คำตอบ:


5

มันไม่สอดคล้องกับ typecasting และลำดับชั้นของการพิมพ์ หากคุณมีวิธีการสองรุ่นหนึ่งในนั้นจะคืนค่าชนิด A และรุ่นที่คืนค่าประเภท B คุณจะพบปัญหาเมื่อ:

  • A หรือ B เป็นชนิดย่อยของกันและกันและคุณกำหนดค่าส่งคืนให้กับประเภท supertype
  • A และ B มี supertype ทั่วไปและคุณกำหนดให้กับค่า supertype เช่นนั้น

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


1
ฉันทำงานกับภาษาที่มีประเภทผลตอบแทนในลายเซ็น การส่งนักแสดงไปทั่วสถานที่นั้นไม่ใช่ปัญหาตามที่คุณระบุ ในตัวอย่างเฉพาะของคุณคุณไม่จำเป็นต้องหลีกเลี่ยงสิ่งนี้ด้วยการปลดเปลื้อง หากทั้ง A และ B (ชนิดย่อยของ C) ทั้งสองมีการดำเนินการเดียวกันมันควรจะประกาศใน C. ถ้าประเภทกลับมาแตกต่างกันสำหรับ A กว่าสำหรับ B: ในกรณีส่วนใหญ่จะพยายามกลับประเภทย่อยของ C. คุณเพียงแค่ เพิ่มวิธีอื่นในประเภทย่อยที่ส่งกลับประเภทย่อยและใช้รุ่นจาก C เพื่อเรียกวิธีหนึ่งที่มีชนิดย่อยเฉพาะ ตอนนี้คุณไม่จำเป็นต้องโยนทั่วสถานที่
Charles Lambert

@Charles Lambert: ไม่ใช่การดำเนินการในคลาส A, B หรือ C มันมีสองฟังก์ชั่นที่มีชื่อและพารามิเตอร์รายการเดียวกันซึ่งหนึ่งในนั้นจะส่งคืนประเภท A และอีกประเภทหนึ่งที่ส่งคืนประเภท B คำถามนี้ใช้ มากกว่าระบบ OOP ดังนั้นฉันจึงตอบตามประเภทและฟังก์ชั่นทั่วไป นอกจากนี้ฉันไม่เข้าใจว่าตัวอย่างการโต้แย้งของคุณมีจุดประสงค์เพื่อให้บรรลุผลอย่างไร ฉันต้องการรายละเอียดเพิ่มเติมเพื่อตอบกลับ
jprete

ความคิดเห็นสั้นเกินไปสำหรับตัวอย่าง pastebin.com/JR39PKs0โดยทั่วไปภาษาที่มีประเภทการส่งคืนในลายเซ็นได้เกิดขึ้นแล้วด้วยวิธีการที่จะบรรเทาปัญหาที่คุณอธิบาย ไม่ว่าจะเป็นแบบแผนการเข้ารหัสหรือแบบฝึกหัดมาตรฐาน นอกจากนี้ยังทราบว่าสิ่งที่คุณเขียนไม่มากนักจะรับประกันวิธีการสร้างที่แตกต่างกันในประเภทผลตอบแทนเท่านั้น ดังนั้นคุณจะไม่ต้องจัดการกับเรื่องนี้บ่อยนัก
ชาร์ลแลมเบิร์ต

จะมีปัญหาใด ๆ หรือไม่ที่มีกฎว่าจะมีการประกาศวิธี "หลัก" เพียงวิธีเดียวสำหรับลายเซ็นอาร์กิวเมนต์ที่กำหนด แต่อาจมีการประกาศจำนวนรองของวิธีการรองได้และผู้รวบรวมควรดำเนินการโอเวอร์โหลดโดยระบุลายเซ็นอาร์กิวเมนต์ มีวิธีการหลักอยู่แล้วจากนั้นตรวจสอบวิธีที่สองตามลำดับที่ระบุเพื่อดูว่าวิธีการดังกล่าวเป็นวิธีการจับคู่ที่ดีกว่าหรือไม่
supercat

3

เพราะคุณสามารถเรียกวิธีการและไม่ได้กำหนดผลลัพธ์


3
ไม่ใช่ทุกภาษา
Jörg W Mittag

@Jorg ชอบภาษาอะไร?
Chiron

1
f # คือหนึ่งภาษา คุณมักเห็น foo -> ไม่สนใจที่จะไม่สนใจเป็นวิธีการที่มีประเภทการกลับมาของหน่วยงานที่มีลักษณะคล้ายกับเป็นโมฆะ
ชาร์ลส์แลมเบิร์

Ada เป็นตัวอย่างที่ดีกว่า ภาษานั้นใช้ชนิดส่งคืนเป็นส่วนหนึ่งของลายเซ็นด้วยเช่นกัน
Charles Lambert

-4

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


1
ฉันอยากรู้ว่าคุณอ้างถึงภาษาใดในภาษาที่พิมพ์อย่างรุนแรงเหล่านี้ ฉันไม่รู้อะไรเลยและฉันรู้ว่า C ++ ห้ามไม่ให้มีการแก้ไขประเภทผลตอบแทนอย่างชัดเจน
greyfade

2
-1 หากคุณจะให้กฎง่ายๆที่ผิดอย่างชัดเจนกับตัวอย่างเดียวที่ละเมิดคุณควรปฏิบัติตามด้วยตัวอย่างอื่น ๆ ทั้งหมดที่มีการปฏิบัติตามกฎ

@ greyfade ประเด็นของฉันคือในภาษาที่พิมพ์อย่างอ่อนการมอบหมายจะไม่ถูกตรวจสอบในเวลารวบรวม เห็นด้วยที่อาจไม่เกี่ยวข้องที่นี่
CMR

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