Closed me2beats closed 3 years ago
In other words, you are proposing to make it possible to declare a named class in multiple files. But isn't it easier to add the ability to (statically) include
the file? Then this feature will also be available in unnamed classes. There is a proposal for include
/import
.
# x1.gd:
class_name X
include 'x2.gd'
var num = 1
func a():
print('a')
# x2.gd:
func b():
print('b')
@dalexeev this is similar, but different. When using include/import in X
, you still have to change X
each time when you want a new file to be included.
Yes, but on the other hand:
x1.gd
you will immediately see all the files in which this class is defined; you don't need to guess if there is still a file that has partial class X
(explicit is better than implicit);include 'x2.gd'
also in Y
, Z
classes i.e. reuse the code (some kind of mixins); this is not possible with your proposal;include
can be used in unnamed classes as well, unlike your suggestion.And can you give me a real example where you need to split a class into several files? I do not find this feature useful (neither your suggestion nor include
), except for the possibility of reusing the code (point 2).
Partial classes are used in several modern and advanced languages, for example in C#
They can make teamwork happier. They are also useful for code generation.
Partial classes don't provide code reuse by themselves, that's true. But they don't limit you to use any other approach for reusing the code.
I have no idea yet how to make them work with unnamed scripts; is that a problem tho? Just make the class named:)
If the question is what to choose: partial classes or include, I don't see a problem here — they both could exist in gdscript and complement each other
I have no idea yet how to make them work with unnamed scripts; is that a problem tho? Just make the class named:)
Considering that named classes go into the global scope, some users prefer to restrain the use of named classes. Although in this particular situation I wouldn't mind requiring this. It does make the feature less flexible.
If the question is what to choose: partial classes or include, I don't see a problem here — they both could exist in gdscript and complement each other
Honestly, I don't to bring everything and the kitchen sink into GDScript. I prefer adding one solution that brings benefit to most users.
My intention is to eventually implement "traits", which works much like an include (but can also work as an interface). I still need to write a proposal for that, hopefully I can put something up soon. This would solve the re-usability part which is indeed a problem of the current system. I believe that would solve most of your points.
I don't really see the usefulness in this. If splitting code into multiple files is needed, you may want to reconsider your class (or potentially use the traits in the future). Same thing for moving across projects. Also, not sure why you don't want to change a particular file for refactoring, a VCS should help you getting back to a working version without losing your work, and if you're only adding functions I'm not sure what would break. Regarding conflicts between team members, it's really only a problem if multiple people are changing the same code which wouldn't be solved by this anyway since people would be working on the same functions and couldn't use the partial class feature. So it seems quite limited to warrant the addition.
It does have downsides too. If you inadvertently make two unrelated files part of the same partial class, it can lead to pretty confusing situations. Especially on a team setting where people are working in different areas but might be using the same partial class name without realizing. Reading code is also hindered because you see a "partial class" and then you have to fishing for the other parts (that may not even exist) in order to understand the whole class.
From the technical point, there's the main problem that one file is one resource in Godot, and as such using a partial class file as the script resource will lead to inconsistencies. If you have part in a.gd
and other part in b.gd
and you use both in different nodes, it's quite difficult to correlate that they are indeed the same script. Using load("a.gd")
needs to be the same as load("b.gd")
which is not great, nor really user-friendly.
All in all, my assessment is that the cons outweigh the pros in this case (also considering that traits should solve most of code-sharing issues).
Сlosing it due to the limitations and lack of consistency in relation to GDScript and in favor of more flexible solutions such as traits.
Describe the project you are working on
Plugins
Describe the problem or limitation you are having in your project
I want to create classes (scripts), the extension of which does not require changes to the script file.
By extension I mean adding new methods, properties signals and classes.
This is useful in different cases:
I often don't want to make changes to the code file that works; refactoring can be an exception. Inadvertent code changes sometimes cause bugs that are not easy to catch.
Separating sections of code - methods and properties - into classes would make it easier to navigate through the code (if the names for the script files are correct and a logical file structure is used).
Сopying and pasting files is more convenient than copying and pasting pieces of code, which is useful when copying code between projects.
You do not lose in performance and memory consumption (if this is critical) with such a separation of scripts (as opposed to inheritance / composition), since the compiler will combine everything into one code.
Finally this approach would lead to less conflicts/merges if working in a team.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Implementing partial classes would solve the problems.
I hope this approach as relatively easy to implement, It is also quite intuitive and requires minimal setting up from the user - he just creates a new script and specifies in it that it is an extension of the class X
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
This is an example of how it could look like
x1.gd:
x2.gd:
This means
X
hasnum
property and alsoa
andb
methods.collisions (like
var num
both inx1.gd
andx2.gd
) should be prohibited and cause an error.all such scripts should have
partial
keywordIf this enhancement will not be used often, can it be worked around with a few lines of script?
There is no way to add new properties and methods without changing the script itself. Partial classes could solve it.
Is there a reason why this should be core and not an add-on in the asset library?
I don't think it could be done using an addon.