ชุมชนภาษาโปรแกรมมิ่ง Zig กำลังมีการอภิปรายอย่างเข้มข้นเกี่ยวกับว่าภาษานี้ควรเพิ่มการรองรับ interface แบบ native หรือไม่ หลังจากมีการเผยแพร่คู่มือรายละเอียดเกี่ยวกับการใช้งาน manual VTable interfaces แม้ว่า Zig จะตั้งใจละเว้นโครงสร้าง interface ที่มีอยู่แล้วเพื่อความเรียบง่าย แต่นักพัฒนาก็เริ่มตั้งคำถามมากขึ้นว่าการเลือกออกแบบนี้สร้างความซับซ้อนที่ไม่จำเป็นสำหรับงานโปรแกรมมิ่งในชีวิตประจำวันหรือไม่
การใช้งาน Interface แบบ Manual สร้างภาระ Boilerplate
แนวทางปัจจุบันในการบรรลุ polymorphism ใน Zig ต้องการให้นักพัฒนาสร้าง VTable interfaces ด้วยตนเองโดยใช้ function pointers และ opaque pointers วิธีการนี้เกี่ยวข้องกับการสร้าง delegate structures ที่แปลง opaque pointers กลับเป็นประเภทเดิม พร้อมกับ vtable function mappings สำหรับแต่ละ interface method แม้ว่าจะใช้งานได้ แต่รูปแบบนี้ต้องการโค้ด boilerplate จำนวนมากที่ต้องเขียนและดูแลรักษาด้วยมือ
สมาชิกในชุมชนแสดงความไม่พอใจกับลักษณะที่ต้องทำซ้ำของแนวทางนี้ การใช้งานแบบ manual ต้องการให้นักพัฒนากำหนดประเภท function pointer สำหรับแต่ละ method สร้าง dispatch logic และจัดการ type casting ซึ่งเป็นงานที่อาจสามารถทำให้เป็นอัตโนมัติได้ นักพัฒนาบางคนกังวลเกี่ยวกับลักษณะที่เสี่ยงต่อข้อผิดพลาดของการเขียนโค้ดรูปแบบเหล่านี้ด้วยมือ โดยเฉพาะเมื่อจำนวน interface methods เพิ่มขึ้น
องค์ประกอบของรูปแบบ VTable Interface Pattern
| องค์ประกอบ | วัตถุประสงค์ |
|---|---|
impl: *anyopaque |
เก็บการ implementation เป็น untyped pointer |
| Function pointers | Vtable pointers ไปยัง method shims |
implBy() method |
เชื่อมต่อ implementation เข้ากับ interface |
| Interface methods | Public API ที่เรียกใช้ vtable |
| Delegate struct | สร้าง original type ใหม่สำหรับการเรียก method |
ความขัดแย้งทางปรัชญาภาษาเกี่ยวกับการรวมฟีเจอร์
การถกเถียงเผยให้เห็นความตึงเครียดพื้นฐานระหว่างปรัชญาแบบมินิมอลของ Zig และความต้องการในการพัฒนาเชิงปฏิบัติ ผู้สร้าง Zig ได้จำกัดฟีเจอร์บางอย่างโดยเจตนาเพื่อป้องกันสิ่งที่พวกเขาพิจารณาว่าเป็นการใช้ในทางที่ผิด รวมถึงข้อจำกัดเกี่ยวกับประเภทที่สร้างขึ้นโดยโปรแกรมที่มี methods การตัดสินใจออกแบบนี้เกิดจากความกังวลเกี่ยวกับการรักษาความเรียบง่ายของภาษาและป้องกันการขยายฟีเจอร์เกินความจำเป็น
อย่างไรก็ตาม นักวิจารณ์โต้แย้งว่าการหลีกเลี่ยงฟีเจอร์เนื่องจากการใช้งานที่ผิดที่อาจเกิดขึ้นนั้นเป็นการบังคับให้ผู้ใช้ทุกคนต้องยอมรับความชอบของผู้ออกแบบภาษา พวกเขาโต้แย้งว่า interfaces ได้กลายเป็นโครงสร้างพื้นฐานที่จำเป็นในภาษาโปรแกรมมิ่งสมัยใหม่ โดยไม่คำนึงถึงระดับการแยกตัวของพวกมัน การอภิปรายนี้เน้นคำถามที่กว้างขึ้นเกี่ยวกับว่าการพัฒนาภาษาที่ขับเคลื่อนโดยผู้เขียนคนเดียวนั้นตอบสนองความต้องการของผู้ใช้ที่หลากหลายได้เพียงพอหรือไม่
การเปรียบเทียบตัวเลือก Polymorphism ใน Zig
| แนวทาง | กรณีการใช้งาน | ประเภทการ Dispatch | การรองรับ Storage |
|---|---|---|---|
| Generics และ comptime | Static polymorphism | Compile-time | ไม่มี uniform type |
| Tagged unions | ชุดประเภทที่ปิดและทราบแล้ว | Runtime | ใช่ |
| VTable interfaces | Dynamic dispatch | Runtime | ใช่ |
รูปแบบที่ไม่สอดคล้องกันทั่วทั้ง Codebase
ความกังวลเชิงปฏิบัติที่สำคัญที่นักพัฒนาหยิบยกขึ้นมาคือการขาดมาตรฐานในการใช้งาน interface ทั่วทั้งโปรเจ็กต์ Zig ที่แตกต่างกัน โดยไม่มีการรองรับจากภาษาโดยตรง แต่ละ codebase มีแนวโน้มที่จะพัฒนาแนวทางของตัวเองสำหรับ interfaces ซึ่งสร้างความไม่สอดคล้องกันและภาระในการเรียนรู้เพิ่มเติม นักพัฒนาต้องตรวจสอบ source code ในแต่ละโปรเจ็กต์เพื่อทำความเข้าใจว่าระบบ interface นั้นๆ ทำงานอย่างไร ตั้งแต่วิธีการเชื่อมต่อไปจนถึงรูปแบบ vtable data member
การแยกส่วนนี้ทำให้ยากต่อการสร้างไลบรารีที่สามารถทำงานร่วมกันได้และเพิ่มภาระทางปัญญาสำหรับนักพัฒนาที่ทำงานข้ามหลายโปรเจ็กต์ Zig สมาชิกในชุมชนบางคนแนะนำว่าแม้จะไม่มีฟีเจอร์ภาษาโดยตรง แต่ตัวช่วยจาก standard library หรือเครื่องมือสร้างโค้ดก็สามารถแก้ไขปัญหาความสอดคล้องเหล่านี้ได้
การแลกเปลี่ยนด้านประสิทธิภาพและหน่วยความจำ
แนวทาง manual VTable ใน Zig แตกต่างจากการใช้งานแบบ C++ ดั้งเดิมในแง่ที่น่าสนใจ แทนที่จะแบ่งปัน vtable เดียวกันทั่วทั้ง instances ของประเภทหนึ่ง รูปแบบที่กล่าวถึงจะแนบข้อมูล vtable กับ interface instances แต่ละตัว สิ่งนี้สร้างการแลกเปลี่ยนระหว่างประสิทธิภาพหน่วยความจำและความยืดหยุ่นในการใช้งาน โดยนักพัฒนาบางคนสังเกตว่าการ indirection เพิ่มเติมอาจส่งผลกระทบต่อประสิทธิภาพเมื่อเปรียบเทียบกับทางเลือก compile-time dispatch
แม้จะมีความกังวลเหล่านี้ ผู้สนับสนุนโต้แย้งว่าผลกระทบต่อประสิทธิภาพยังคงน้อยที่สุดในขณะที่ให้ความยืดหยุ่นที่จำเป็นสำหรับ heterogeneous collections และสถานการณ์ dynamic dispatch ที่ compile-time generics ไม่สามารถจัดการได้
การอภิปรายที่กำลังดำเนินอยู่สะท้อนคำถามที่กว้างขึ้นเกี่ยวกับวิวัฒนาการของภาษาและความสมดุลระหว่างความเรียบง่ายและผลิตภาพของนักพัฒนา ขณะที่ Zig เข้าใกล้การเปิดตัวเวอร์ชัน 1.0 ชุมชนยังคงต่อสู้กับคำถามว่าความสะดวกสบายบางอย่างควรจะถูกสร้างเข้าไปในภาษาหรือยังคงเป็นความรับผิดชอบของนักพัฒนาและผู้เขียนไลบรารีแต่ละคน
อ้างอิง: Zig Interface Revisited