Implement namespaces in GDScript
<!-- Please fill in *all* the questions below and don't remove any of them. Proposals not following the template below will be closed immediately. --> **Describe the project you are working on:** GDScript plugins **Describe the problem or limitation you are having in your project:** `class_name` is a great feature and I use it often when making plugins. But there are at least 3 problems which can occur when using `class_name`: 1. If you use a custom class named say `Util` when creating a plugin, there is absolutely no guarantee that the user is not using a custom type with the same name. So you will get > Unique global class "Utils" already exists 2. As the number of your custom classes gets large (imagine a room with several hundred items on the floor), you will most likely want to structure them by dividing them into logical parts (arrange all items on their shelves) for easier access. But in this case, you will face various challenges, and it seems that none of the solutions will be truly convenient especially if you want to keep having each class separately (i.e. don't use nested classes) 3. Littering the global namespace as a whole. all custom classes are visible in the global namespace. The user might mistakenly try to use your class. also a large number of custom classes clogs up the autocomplete. thus, having a large number of custom classes is incompatible with ease of development, which, as the code base of the project grows, will force the developer to ab
Posted by me2beats on Sep 25, 2020, 6:18 AM
Tags
Related issues
- struct's lifetime requirements can be bypassed via covariant field assignment
- Proposal to Reorganize the Moderation Team and Review Moderation Policies
- Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
- proposal: container/...: generic collection types
- Better Custom Endpoint BYOK
- A concrete policy for backward compatibility until Godot 5.0
Raise real-world problems, find people facing the same issue, and discuss solutions.3,000 issues0 comments
github (Other)
struct's lifetime requirements can be bypassed via covariant field assignment
Proposal to Reorganize the Moderation Team and Review Moderation Policies
Progressive FPS degradation appears to be related to dota2.com — blocking the domain prevents the performance loss
proposal: container/...: generic collection types
Better Custom Endpoint BYOK
A concrete policy for backward compatibility until Godot 5.0
New MTP models not supported
Tracking: 429 / Capacity Issues
Implement namespaces in GDScript
<!-- Please fill in *all* the questions below and don't remove any of them. Proposals not following the template below will be closed immediately. --> **Describe the project you are working on:** GDScript plugins **Describe the problem or limitation you are having in your project:** `class_name` is a great feature and I use it often when making plugins. But there are at least 3 problems which can occur when using `class_name`: 1. If you use a custom class named say `Util` when creating a plugin, there is absolutely no guarantee that the user is not using a custom type with the same name. So you will get > Unique global class "Utils" already exists 2. As the number of your custom classes gets large (imagine a room with several hundred items on the floor), you will most likely want to structure them by dividing them into logical parts (arrange all items on their shelves) for easier access. But in this case, you will face various challenges, and it seems that none of the solutions will be truly convenient especially if you want to keep having each class separately (i.e. don't use nested classes) 3. Littering the global namespace as a whole. all custom classes are visible in the global namespace. The user might mistakenly try to use your class. also a large number of custom classes clogs up the autocomplete. thus, having a large number of custom classes is incompatible with ease of development, which, as the code base of the project grows, will force the developer to ab
Comments (0)
No comments yet. Start the discussion.