Hệ thống mô-đun cho ngôn ngữ OOP

Tôi đang thiết kế một ngôn ngữ lập trình OO đơn giản.

Nó được gõ, biên dịch và thực thi tĩnh bởi một VM - tương tự như Java.

Sự khác biệt là tôi không muốn có sự nhấn mạnh như vậy vào OOP. Bản thân mã sẽ giống với C ++ (các lớp, hàm và các biến được phép trong phạm vi tệp).

Một trong những điều mà tôi cần phải có là một hệ thống mô-đun. Tôi có những điều sau đây đã tìm ra:

1. Mỗi tệp là một mô-đun (một khi được biên dịch) - như Python
2. Các lập trình viên phải nhập một mô-đun với importtừ khóa, điều này khiến trình biên dịch tìm kiếm các mô-đun trong các thư mục tiêu chuẩn và thư mục tệp (VM ​​cũng phải làm điều này khi chạy).

Và bây giờ tôi không biết làm thế nào tôi nên giới thiệu khái niệm mô hình con và phân cấp mô-đun.

Chẳng hạn, một tùy chọn là phụ thuộc vào hệ thống phân cấp thư mục, do đó import engine.graphics.renderersẽ mong muốn tìm thấy một thư mục có tên là "engine" trong thư mục làm việc và bên trong một thư mục có tên là "đồ họa", với một mô-đun gọi là "renderer".

Nhược điểm của một thiết kế như vậy là gì? Tôi có thiếu thứ gì không?

Hãy xem phân cấp / tổ chức mô-đun / mô-đun của Python và đặc biệt là ở khía cạnh lịch sử, những bổ sung chính trong suốt nhiều năm, quan trọng nhất là những thứ mới nhất. Có lẽ, không có ý nghĩa trong việc phát minh ra bánh xe.

Tôi không biết bạn muốn đi bao xa với ngôn ngữ của mình, vd

• Bạn có muốn các mô-đun mã byte được đọc từ zip?
• Làm thế nào để bạn tách các mô-đun / thư viện cho các phiên bản thông dịch viên khác nhau?
• Bạn có kế hoạch để làm cho nó dường như vô tận với distro?
• Đừng quên sự dễ dàng trong phân phối riêng của ngôn ngữ (nghĩ rằng distutils / pypi - mỗi nền tảng / ngôn ngữ có một thứ riêng, không phải lúc nào cũng tốt)

Tôi đoán, Java có thể là một ví dụ thú vị khác. Mọi thứ cũng có thể được học theo cách của Erlang (ví dụ: /programming/2968914/code-hot-swicking-in-erlang ).

Có rất nhiều vấn đề thiết kế (một số chạm ở trên) nếu bạn có kế hoạch để xem ngôn ngữ lập trình của bạn một ngày nào đó. May mắn thay, có những ví dụ tuyệt vời ngoài kia.

Một số hướng ngôn ngữ lập trình mô-đun / gói / thiết kế hệ thống thư viện nên giải quyết:

• mã trực quan cho cả viết và sử dụng mô-đun
• các đối tượng mô-đun / gói trong mã
• khả năng hướng nội mô-đun / gói
• đóng gói mô-đun / gói (làm thế nào để ẩn các chi tiết không cần thiết?)
• sử dụng giao diện / tập tin tiêu đề?
• hệ thống điều phối hạt mịn, mà cả hai công cụ phân phối riêng của ngôn ngữ cũng như các tiện ích cấp hệ thống đều có thể sử dụng (tránh "địa ngục DLL")
• nơi lưu trữ cho các mô-đun được biên dịch
• hệ thống thiết lập, tự động biên dịch cả mô-đun "thuần túy" và mô-đun / phụ thuộc
• vị trí chuẩn của mã được biên dịch, kiểm tra, tài liệu, tài sản trong mô-đun của bạn

Trước hết, hãy giả sử rằng bạn ánh xạ mô hình không gian tên của mình sang một không gian tên khác, chẳng hạn như hệ thống tệp, như bạn đã đề xuất. Thứ hai, tôi giả định rằng các mô-đun có thể nhập các mô-đun khác. Nói cách khác, engine.graphics.rendererrất có thể chứa một dòng như import circle.arc. Điều đó đặt ra hai vấn đề:

• VM sẽ tìm ở circle.arcđâu? Theo sơ đồ hệ thống tập tin mappimg đã đề cập, cần có một thư mục như /etc/mylang/modules/circle/arc ( /etc/mylang/moduleslà gốc của cấu trúc mô-đun của bạn) .

• Làm thế nào một tài liệu tham khảo ứng dụng circle.arc: bằng cách importing circle.archoặc engine.graphics.render.circle.arc? Cái đầu tiên sẽ "làm hỏng" (nếu không phá hỏng) hệ thống phân cấp, bởi vì circle.arcrõ ràng là một mô hình con engine.graphics.renderervà thứ hai sẽ ngụ ý rằng cần phải có một /etc/mylang/modules/engine/graphics/renderer/circle/archệ thống tập tin của bạn, đặt circle.arcđồng thời hai vị trí.

Có nói rằng, và nếu bạn quyết định đi theo cách tiếp cận không gian tên, ánh xạ nó đến hệ thống tập tin có vẻ quá hạn chế đối với tôi. Tôi nghĩ rằng các mô-đun có thể cư trú ở tất cả các loại địa điểm khác nhau (ngay cả các tệp zip, như đã đề cập, thậm chí các url). VM sẽ bắt đầu bằng cách tìm kiếm một mục trong một loại chỉ mục (có thể là tệp cấu hình) để ánh xạ không gian tên đến các vị trí mô-đun thực tế.