ภาษาตามจำนวน จำกัด ของอาร์กิวเมนต์ที่ส่งผ่านไปยังฟังก์ชัน

แนวคิดนี้ได้รับแรงบันดาลใจจากตัวดำเนินการข้อเท็จจริงเช่น +, -,%, เป็นต้นซึ่งสามารถมองเห็นได้ว่าเป็นฟังก์ชั่นที่ผ่านการโต้แย้งหนึ่งหรือสองครั้งและไม่มีผลข้างเคียง สมมติว่าฉันหรือคนอื่นเขียนภาษาที่หยุดไม่ให้มีการโต้แย้งมากกว่าสองข้อและยังใช้งานได้ผ่านการส่งคืนเท่านั้น:

ก) ภาษานั้นจะทำให้เข้าใจรหัสได้ง่ายขึ้นหรือไม่

b) การไหลของรหัสจะชัดเจนขึ้นหรือไม่ (บังคับให้ทำตามขั้นตอนมากขึ้นโดยที่การโต้ตอบ 'ซ่อน' อาจมีน้อยลง

c) ข้อ จำกัด จะทำให้ภาษามีขนาดใหญ่เกินไปสำหรับโปรแกรมที่ซับซ้อนมากขึ้น

d) (โบนัส) ความคิดเห็นอื่น ๆ เกี่ยวกับข้อดี / ข้อเสีย

บันทึก:

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

Robert C. Martin ในหนังสือของเขา "Clean Code" แนะนำให้ใช้ฟังก์ชั่นอย่างมากด้วยพารามิเตอร์สูงสุด 0, 1 หรือ 2 ดังนั้นอย่างน้อยก็มีผู้เขียนหนังสือที่มีประสบการณ์คนหนึ่งที่คิดว่าโค้ดสะอาดขึ้นโดยใช้สไตล์นี้ แน่นอนว่าไม่ใช่อำนาจสูงสุดที่นี่และความคิดเห็นของเขาก็เป็นที่ถกเถียงกันอยู่)

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

อย่างไรก็ตามฉันไม่คิดว่ามันเป็นความคิดที่ดีที่จะประดิษฐ์ภาษาใหม่สำหรับสิ่งนี้:

• หากคุณต้องการบังคับใช้กฎดังกล่าวตลอดทั้งรหัสของคุณคุณเพียงต้องการเครื่องมือวิเคราะห์รหัสสำหรับภาษาที่มีอยู่ไม่จำเป็นต้องคิดค้นภาษาใหม่อย่างสมบูรณ์สำหรับสิ่งนี้ (ตัวอย่างเช่นสำหรับ C # บางสิ่งเช่น 'fxcop' )

• บางครั้งการรวมพารามิเตอร์กับประเภทใหม่ดูเหมือนจะไม่คุ้มค่ากับความยุ่งยากหรืออาจกลายเป็นการผสมผสานที่บริสุทธิ์ ดูตัวอย่างวิธีนี้File.Openจาก. Net framework ใช้พารามิเตอร์สี่ตัวและฉันค่อนข้างมั่นใจว่าผู้ออกแบบของ API นั้นทำสิ่งนี้โดยเจตนาเพราะพวกเขาคิดว่าจะเป็นวิธีที่ใช้งานได้จริงที่สุดในการมอบพารามิเตอร์ที่แตกต่างให้กับฟังก์ชัน

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

มีภาษามากมายที่ใช้วิธีนี้แล้วเช่น Haskell ใน Haskell ทุกฟังก์ชั่นใช้อาร์กิวเมนต์หนึ่งค่าและส่งกลับค่าเดียว

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

สิ่งนี้เรียกว่า Frege-Schönfinkeling, Schönfinkeling, Schönfinkel-Currying หรือ Currying หลังจาก Haskell Curry ผู้วิจัยเรื่องนี้อย่างกว้างขวางในปี 1950 โมเสสSchönfinkelผู้อธิบายไว้ในปี 1924

กล่าวอีกนัยหนึ่งการ จำกัด จำนวนอาร์กิวเมนต์มีผลกระทบเป็นศูนย์อย่างแน่นอน

ฉันใช้เวลาในช่วงสองสามสัปดาห์ที่ผ่านมานี้เพื่อพยายามเรียนรู้ภาษาคอมพิวเตอร์ J ใน J เกือบทุกอย่างเป็นตัวดำเนินการดังนั้นคุณจะได้รับ "monads" (ฟังก์ชั่นที่มีเพียงหนึ่งอาร์กิวเมนต์เท่านั้น) และ "dyads" (ฟังก์ชั่นที่มีอาร์กิวเมนต์สองตัว) หากคุณต้องการอาร์กิวเมนต์เพิ่มเติมคุณต้องระบุในอาร์เรย์หรือระบุใน "กล่อง"

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

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

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

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

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

คุณจะต้องมีสองสิ่ง:

• การปิด
• ประเภทข้อมูลคอมโพสิต

ฉันจะเพิ่มเป็นตัวอย่างทางคณิตศาสตร์เพื่ออธิบายคำตอบที่เขียนโดยJörg W Mittag

พิจารณาฟังก์ชั่นเสียน

ฟังก์ชั่นเสียนมีสองพารามิเตอร์สำหรับรูปร่างของมันคือค่าเฉลี่ย (ตำแหน่งกึ่งกลางของเส้นโค้ง) และความแปรปรวน (เกี่ยวข้องกับความกว้างพัลส์ของเส้นโค้ง) นอกเหนือจากพารามิเตอร์สองตัวหนึ่งยังต้องระบุค่าของตัวแปรอิสระxเพื่อประเมิน

ในขั้นตอนแรกเราจะออกแบบฟังก์ชั่นแบบเกาส์ที่รับพารามิเตอร์ทั้งสาม ได้แก่ ค่าเฉลี่ยความแปรปรวนและตัวแปรอิสระ

ในขั้นตอนที่สองเราสร้างประเภทข้อมูลคอมโพสิตที่รวมค่าเฉลี่ยและความแปรปรวนเป็นสิ่งเดียว

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

ในที่สุดเราประเมินการปิดที่สร้างขึ้นในขั้นตอนที่สามโดยส่งค่าของตัวแปรอิสระxให้กับมัน

โครงสร้างจึงเป็น:

• ประเมิน (การคำนวณ)
  • ParameterizedGaussian (การปิด: สูตรพร้อมตัวแปรที่ถูกผูกไว้)
    • GaussianParameters (ประเภทข้อมูลคอมโพสิต)
      • ค่าเฉลี่ย (ค่า)
      • ความแปรปรวน (ค่า)
  • X (ค่าของตัวแปรอิสระ)

1. ในเกือบทุกภาษาการเขียนโปรแกรมคุณสามารถส่งบางประเภทของรายการอาร์เรย์ tuple บันทึกหรือวัตถุเป็นอาร์กิวเมนต์เท่านั้น มีวัตถุประสงค์เพียงเพื่อเก็บสิ่งของอื่น ๆ แทนที่จะส่งไปยังฟังก์ชั่นทีละรายการ Java IDE บางตัวมีคุณสมบัติ " แยกพารามิเตอร์พารามิเตอร์ " เพื่อทำเช่นนั้น ภายใน Java ดำเนินการจำนวนตัวแปรของข้อโต้แย้งโดยการสร้างและผ่านอาร์เรย์

2. หากคุณต้องการทำสิ่งที่คุณกำลังพูดถึงในรูปแบบที่บริสุทธิ์ที่สุดคุณต้องดูแคลคูลัสแลมบ์ดา มันเป็นสิ่งที่คุณอธิบาย คุณสามารถค้นหาเว็บสำหรับมัน แต่คำอธิบายที่ทำให้รู้สึกถึงฉันอยู่ในประเภทและการเขียนโปรแกรมภาษา

3. ดูภาษาการเขียนโปรแกรมHaskellและML (ML นั้นง่ายกว่า) พวกเขาทั้งสองขึ้นอยู่กับแคลคูลัสแลมบ์ดาและแนวคิดมีเพียงหนึ่งพารามิเตอร์ต่อฟังก์ชั่น (ถ้าคุณเหล่เล็กน้อย)

4. รายการที่ 2 ของ Josh Bloch คือ: "พิจารณาตัวสร้างเมื่อเผชิญกับพารามิเตอร์ตัวสร้างจำนวนมาก" คุณสามารถดูว่าสิ่งนี้ได้รับอย่างไร แต่ก็ยินดีที่ได้ทำงานกับ API ที่เขียนด้วยวิธีนี้

5. บางภาษามีการตั้งชื่อพารามิเตอร์ซึ่งเป็นอีกวิธีหนึ่งในการทำให้ลายเซ็นของวิธีการขนาดใหญ่นำทางได้ง่ายกว่ามาก Kotlin ได้ตั้งชื่ออาร์กิวเมนต์เช่น