PHP 8.5 Pipe Operator จุดประกายการถกเถียงเรื่องไวยากรณ์และประสิทธิภาพเมื่อเทียบกับการพัฒนาที่หยุดชะงักของ JavaScript

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

ตัวอย่างไวยากรณ์ Pipe Operator ใน PHP 8.5:

// การใช้ pipe แบบพื้นฐาน
$result = "Hello World" > strlen(...);

// การดำเนินการแบบต่อเชื่อม
$result = $arr
    > fn($x) => array_column($x, 'tags')
    > fn($x) => array_merge(...$x)
    > array_unique(...)
    > array_values(...);

// การเรียกใช้ฟังก์ชันแบบซ้อนที่เทียบเท่า
array_values(array_unique(array_merge(...array_column($arr, 'tags'))));

ชุมชน JavaScript เฝ้าดูด้วยความอิจฉา

การประกาศ pipe operator ของ PHP ได้กระทบจิตใจของโลก JavaScript ที่นักพัฒนาได้รอคอยฟังก์ชันคล้ายกันมานานกว่าทศวรรษ ข้อเสนอ pipe operator ของ JavaScript ยังคงติดอยู่ใน stage 2 ของกระบวนการ TC39 โดยผู้พัฒนา engine ได้ยกประเด็นความกังวลเรื่องประสิทธิภาพของการสร้าง closure สิ่งนี้ทำให้เกิดความผิดหวังในหมู่นักพัฒนา JavaScript ที่เห็น PHP สามารถพัฒนาสิ่งที่พวกเขาต้องการมานานได้สำเร็จ

ความแตกต่างนี้ชัดเจนเป็นพิเศษเพราะ JavaScript ใช้งาน temporary closure อย่างหนักผ่านระบบ async/await อยู่แล้ว ทำให้ข้อโต้แย้งเรื่องประสิทธิภาพดูไม่สอดคล้องกันสำหรับนักพัฒนาหลายคน สมาชิกชุมชนบางคนตั้งคำถามว่าผู้พัฒนา engine ควรจะกำหนดรูปแบบการเขียนโปรแกรมในระดับที่มากขนาดนี้หรือไม่

สถานะ Pipe Operator ของ JavaScript เทียบกับ PHP:

ข้อจำกัดของไวยากรณ์ทำให้เกิดความกังวลในการใช้งานจริง

แม้ว่า pipe operator จะทำให้โค้ดสะอาดขึ้น แต่นักพัฒนา PHP กำลังค้นพบข้อจำกัดที่สำคัญซึ่งอาจส่งผลต่อการใช้งานในโลกจริง operator นี้ต้องการให้ฟังก์ชันทั้งหมดในห่วงโซ่รับพารามิเตอร์เพียงหนึ่งตัวเท่านั้น และค่าที่ถูก pipe จะไปยังตำแหน่งพารามิเตอร์แรกเสมอ สิ่งนี้สร้างปัญหากับ standard library ของ PHP ที่มีความไม่สอดคล้องกันอย่างฉาวโฉ่ ซึ่งฟังก์ชันอย่าง array_key_exists() คาดหวัง array เป็นพารามิเตอร์ตัวที่สอง

วิธีแก้ไขปัญหานี้ต้องใช้การห่อฟังก์ชันที่มีปัญหาด้วย closure ซึ่งนักพัฒนาบางคนโต้แย้งว่าทำลายจุดประสงค์ของการมี pipe operator ตั้งแต่แรก ข้อจำกัดนี้บังคับให้นักพัฒนาต้องเขียน lambda function ที่ยาวแทนที่จะเป็นการเรียกใช้ฟังก์ชันโดยตรงที่สะอาดตามที่พวกเขาหวังไว้

ข้อจำกัดหลักของ Pipe Operator ใน PHP :

• ฟังก์ชันทั้งหมดต้องรับพารามิเตอร์ที่จำเป็นเพียงหนึ่งตัวเท่านั้น
• ค่าที่ส่งผ่าน pipe จะไปอยู่ในตำแหน่งพารามิเตอร์แรกเสมอ
• ไม่สามารถเปลี่ยนตำแหน่งพารามิเตอร์ภายใน pipe ได้
• ฟังก์ชันในตัวที่ไม่มีพารามิเตอร์ไม่สามารถใช้ใน chain ได้
• ต้องใช้ closure wrapping สำหรับฟังก์ชันที่มีการจัดเรียงพารามิเตอร์ที่ไม่สอดคล้องกัน

คำถามเรื่องประสิทธิภาพและประสิทธิภาพของหน่วยความจำ

การอภิปรายในชุมชนเผยให้เห็นความกังวลเกี่ยวกับประสิทธิภาพของ pipe operator เมื่อเปรียบเทียบกับทางเลือกอื่น ไม่เหมือนกับ Unix shell pipe ที่ stream ข้อมูล การพัฒนาของ PHP สร้างตัวแปรชั่วคราวในแต่ละขั้นตอน ซึ่งอาจใช้หน่วยความจำมากกว่าวิธีการแบบดั้งเดิม นักพัฒนาบางคนตั้งคำถามว่าประโยชน์ด้านความสามารถในการอ่านคุ้มค่ากับ overhead หรือไม่ โดยเฉพาะสำหรับงานประมวลผลข้อมูลขนาดใหญ่

การถกเถียงขยายไปถึงว่า PHP ควรจะเน้นไปที่โซลูชันแบบ iterator-based หรือ extension method แทน ซึ่งสามารถให้ความสามารถในการอ่านที่คล้ายกันพร้อมกับลักษณะประสิทธิภาพที่ดีกว่า

ความไม่สอดคล้องกันของ Standard Library ทำให้ปัญหารุนแรงขึ้น

pipe operator ได้เน้นย้ำปัญหาที่มีมานานของ standard library ของ PHP นั่นคือการเรียงลำดับพารามิเตอร์ที่ไม่สอดคล้องกัน ฟังก์ชันอย่าง array_filter() และ array_map() รับพารามิเตอร์ในลำดับที่แตกต่างกัน ทำให้การใช้งานใน pipe chain เป็นเรื่องที่น่าอึดอัด ความไม่สอดคล้องกันนี้ซึ่งสืบทอดมาจาก C library พื้นฐาน กลายเป็นปัญหามากขึ้นเมื่อพยายามสร้าง function pipeline ที่ราบรื่น

stdlib มีความไม่สอดคล้องกันมากจนสิ่งนี้จะกลายเป็นฝันร้าย นักพัฒนา PHP ควรจะเน้นไปที่การสนับสนุน unicode อย่างเต็มรูปแบบก่อน และจึงค่อยเน้นไปที่ stdlib แบบ namespace ใหม่ที่มีการออกแบบที่ดีกว่า

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

แนวโน้มในอนาคตและการพัฒนาของภาษา

แม้จะมีการวิพากษ์วิจารณ์ แต่นักพัฒนา PHP จำนวนมากมองว่า pipe operator เป็นก้าวสู่รูปแบบการเขียนโปรแกรมที่ทันสมัยกว่า ฟีเจอร์นี้ทำงานได้ดีกับไวยากรณ์ first-class callable ที่มีอยู่ของ PHP และเปิดประตูสำหรับการปรับปรุงในอนาคต เช่น partial function application และ function composition operator ที่วางแผนไว้สำหรับเวอร์ชันหลังๆ

การพัฒนานี้แสดงถึงการพัฒนาต่อเนื่องของ PHP จากรากฐานแบบ procedural ไปสู่การสนับสนุนรูปแบบ functional programming แม้ว่าการดำเนินการจะไม่สมบูรณ์แบบ สำหรับภาษาที่มักถูกวิพากษ์วิจารณ์เรื่องความไม่สอดคล้องกันในการออกแบบ pipe operator แสดงให้เห็นความเต็มใจของ PHP ที่จะนำฟีเจอร์จากภาษาที่ทันสมัยกว่ามาใช้ แม้ว่าการปรับใช้จะไม่ราบรื่นนัก

อ้างอิง: PHP 8.5 Adds Pipe Operator: What it means