Cộng đồng ngôn ngữ lập trình Zig đang tham gia vào một cuộc thảo luận sôi nổi về việc liệu ngôn ngữ này có nên bổ sung hỗ trợ giao diện gốc hay không, sau khi xuất bản một hướng dẫn chi tiết về việc triển khai giao diện VTable thủ công. Trong khi Zig cố ý bỏ qua các cấu trúc giao diện tích hợp để ưu tiên tính đơn giản, các nhà phát triển ngày càng đặt câu hỏi liệu lựa chọn thiết kế này có tạo ra sự phức tạp không cần thiết cho các tác vụ lập trình hàng ngày hay không.
Triển khai giao diện thủ công tạo ra gánh nặng mã boilerplate
Cách tiếp cận hiện tại để đạt được tính đa hình trong Zig yêu cầu các nhà phát triển phải xây dựng thủ công các giao diện VTable bằng cách sử dụng con trỏ hàm và con trỏ mờ. Phương pháp này bao gồm việc tạo các cấu trúc delegate để ép kiểu con trỏ mờ về kiểu gốc của chúng, cùng với việc ánh xạ hàm vtable cho mỗi phương thức giao diện. Mặc dù có thể hoạt động được, mô hình này đòi hỏi một lượng mã boilerplate đáng kể phải được viết và duy trì bằng tay.
Các thành viên cộng đồng bày tỏ sự thất vọng với tính chất lặp đi lặp lại của cách tiếp cận này. Việc triển khai thủ công yêu cầu các nhà phát triển phải định nghĩa các kiểu con trỏ hàm cho mỗi phương thức, tạo logic điều phối và xử lý việc ép kiểu - những công việc có thể được tự động hóa. Một số nhà phát triển lo ngại về tính chất dễ gây lỗi khi viết tay các mô hình này, đặc biệt khi số lượng phương thức giao diện tăng lên.
Các Thành Phần của Mẫu Thiết Kế VTable Interface
| Thành Phần | Mục Đích |
|---|---|
impl: *anyopaque |
Lưu trữ implementation dưới dạng con trỏ không kiểu |
| Con trỏ hàm | Con trỏ vtable đến các method shim |
Phương thức implBy() |
Kết nối implementation với interface |
| Các phương thức interface | API công khai gọi vào vtable |
| Cấu trúc delegate | Tái tạo kiểu gốc cho các lời gọi phương thức |
Xung đột triết lý ngôn ngữ về việc bao gồm tính năng
Cuộc tranh luận tiết lộ một căng thẳng cơ bản giữa triết lý tối giản của Zig và nhu cầu phát triển thực tế. Người tạo ra Zig đã cố ý hạn chế một số tính năng để ngăn chặn những gì họ coi là lạm dụng tiềm tàng, bao gồm các hạn chế về việc các kiểu được xây dựng theo chương trình có phương thức. Quyết định thiết kế này xuất phát từ mối quan tâm về việc duy trì tính đơn giản của ngôn ngữ và ngăn chặn sự phình to tính năng.
Tuy nhiên, những người chỉ trích lập luận rằng việc tránh các tính năng do lo ngại lạm dụng tiềm tàng sẽ áp đặt sở thích của người thiết kế ngôn ngữ lên tất cả người dùng. Họ cho rằng các giao diện đã trở thành cơ sở hạ tầng thiết yếu trong các ngôn ngữ lập trình hiện đại, bất kể mức độ trừu tượng của chúng. Cuộc thảo luận làm nổi bật những câu hỏi rộng lớn hơn về việc liệu phát triển ngôn ngữ theo hướng tác giả có phục vụ đầy đủ nhu cầu đa dạng của người dùng hay không.
So sánh các lựa chọn đa hình trong Zig
| Phương pháp | Trường hợp sử dụng | Loại phân phối | Hỗ trợ lưu trữ |
|---|---|---|---|
| Generics và comptime | Đa hình tĩnh | Thời gian biên dịch | Không có kiểu thống nhất |
| Tagged unions | Tập hợp đóng các kiểu đã biết | Thời gian chạy | Có |
| Giao diện VTable | Phân phối động | Thời gian chạy | Có |
Các mô hình không nhất quán trên các codebase
Một mối quan tâm thực tế đáng kể được các nhà phát triển nêu ra là việc thiếu tiêu chuẩn hóa trong các triển khai giao diện trên các dự án Zig khác nhau. Không có hỗ trợ ngôn ngữ gốc, mỗi codebase có xu hướng phát triển cách tiếp cận riêng đối với giao diện, tạo ra sự không nhất quán và gánh nặng học tập. Các nhà phát triển phải kiểm tra mã nguồn trong mỗi dự án để hiểu cách hoạt động của sơ đồ giao diện cụ thể đó, từ các phương thức kết nối đến các sơ đồ thành viên dữ liệu vtable.
Sự phân mảnh này khiến việc xây dựng các thư viện có thể tương tác trở nên khó khăn và tăng tải nhận thức cho các nhà phát triển làm việc trên nhiều dự án Zig. Một số thành viên cộng đồng đề xuất rằng ngay cả khi không có các tính năng ngôn ngữ gốc, các công cụ hỗ trợ thư viện tiêu chuẩn hoặc công cụ tạo mã có thể giải quyết những vấn đề nhất quán này.
Đánh đổi hiệu suất và bộ nhớ
Cách tiếp cận VTable thủ công trong Zig khác với các triển khai C++ truyền thống theo những cách thú vị. Thay vì chia sẻ một vtable duy nhất trên tất cả các instance của một kiểu, mô hình được thảo luận gắn thông tin vtable vào các instance giao diện riêng lẻ. Điều này tạo ra sự đánh đổi giữa hiệu quả bộ nhớ và tính linh hoạt triển khai, với một số nhà phát triển lưu ý rằng việc gián tiếp bổ sung có thể ảnh hưởng đến hiệu suất so với các lựa chọn thay thế điều phối thời gian biên dịch.
Bất chấp những mối quan tâm này, những người ủng hộ lập luận rằng tác động hiệu suất vẫn tối thiểu trong khi cung cấp tính linh hoạt cần thiết cho các bộ sưu tập không đồng nhất và các tình huống điều phối động mà generics thời gian biên dịch không thể xử lý.
Cuộc thảo luận đang diễn ra phản ánh những câu hỏi rộng lớn hơn về sự phát triển ngôn ngữ và sự cân bằng giữa tính đơn giản và năng suất của nhà phát triển. Khi Zig tiến gần đến bản phát hành 1.0, cộng đồng tiếp tục vật lộn với việc liệu một số tiện ích nhất định có nên được tích hợp vào ngôn ngữ hay vẫn là trách nhiệm của các nhà phát triển cá nhân và tác giả thư viện.
Tham khảo: Zig Interface Revisited