-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Idea for adding support for multiple classes in one file. #59
Comments
Oh no - you're going to be annoyed with me for this but I've actually already implemented multiple classes in a single file! That TODO list is sadly out of date (I was maintaining it back when no one was actually using this project.... lol). Just so you know, the most up-to-date list of things to do on this project can be found here: https://github.com/johnfn/ts2gd/blob/main/main.ts#L3 I suppose I should update the README to have this information in it. :) |
Two quick comments about your implementation though:
|
Nah, don't worry. I suspected that it is already implemented by looking at the code. I also do not prefer My thought was just that default classes are very similiar to godot main class in .gd file. Also it would be very natural for people using default export to think that this is a main class. |
One thing that I do not like about current solution is that one |
Wow I didn't know that about default imports, thats awesome :) Yeah it makes sense for people to think the default class is the main one, but how would that affect the TS code? I feel like all the TS code would be the same with either implementation - except I guess we could allow import Blah from file... |
Ah yeah, I hear you on one ts -> multiple gd being counterintuitive, but the thing is, how else are you supposed to add two classes from the same script to different scenes? At least thats what I was imagining it would be used for... |
For an app like Mainly I think that everything that is possible to do in gdscript should be possible to be represented in TypeScript. In a easy way that TS developers understand of course. Creating multiple classes in one file is very frequent for someone using TS, but then we generate multiple files when we could just create inner classes. From TypeScript point currently we would only add |
Here is an example what it could look like: export default class MyNode {
a: int
}
export class HelperClass {
b: string
}
// Class that is not exported have no sense in gdscript, but in TS we can
// use this to limit someone from using that class through an import.
// This is important when we are writing a library for example
// Both cases with export and no export would generate same code for gdscript.
class NotExportedClass {
c: boolean
} Example generated code class_name MyNode
var a: int
class HelperClass:
var b: int
class NotExportedClass
var c: boolean When you look at both codes you can clearly see exactly which part of gdscript is generated from which lines of TypeScript. |
Godot separates inner classes from the main ones, because inner classes cannot be used to create a node and they also cannot be used to attach a script. We should also tell people that |
Hmm, I don't understand why the goal would be to generate all possible gdscript? In my mind the goal has always been for people using ts2gd to write their entire project in TS, without ever having to worry what the generated GD looks like. So, in my mind, we should target all possible TS, but not worry about targeting all possible GD. Unless you're thinking of some TS-GD interoperability? But I can't think of how not having inner classes would hamper interoperability... Open to be convinced the other way though! |
If you want to make ts2gd popular and usable you need to take account what kind of people can use it and what would they like in such tool. I see at least thee kinds of people:
I really like this project, because I myself do not like python syntax style. What I would really like is that the code I write in TypeScript gets converted to GDScript in a natural way which should not need a lot of additional explanations. I hope my opinion does not scare you ;)
No i do not think right now about interoperability, more likely about reflection of TS code in GDScript code and vice versa for easier learning curve. It would be so nice if this project could attract more TS developers to create games in godot :D |
By all means keep sending me more scary opinions! :D Preface: the way I've been thinking of the use cases around ts2gd converting TS to GD is in the same way that I think about how TypeScript converts TS to JS. E.g. most people these days just write TS and don't worry too much about the JS output. In fact, when I write TS I basically never look at the JS at all. However I see that maybe the core issue here is in inspecting the output and making sure it's sane. I kinda noticed that with everyone else as well, that they wanted to inspect the output to make sure it makes sense. I definitely wasn't thinking about that case before, but it seems pretty important. It's kinda hard to do this all the time, I mean even right now we emit a ton of I think the thing I don't understand is if inner classes are really making the code less readable? I suppose that it's a bit less intuitive if the class ends up in a separate file - they could be confused wondering where it ended up. |
One thing I would add as that we should consider the debugging experience within Godot. |
The thing is that TypeScript has been around for a long time now. There is no need to check if it generates good JS code because with such maturity a lot of people can just blindly trust it. Through my long experience with TS I had few situations where it generated not valid or the output in JS was really different from what I expected. Of course with next updates TS usually was fixed, but still it is not always good to fully trust a program without good understand what is underneath in its implementation. |
@johnfn I've implemented most of needed features for this change in PR #61 you can review the code and decide what direction you want to take. If you don't like it then we can try to figure out some other solution. Also don't worry I won't cry if you reject all my code in this PR ;) I just wanted to show to you how in my opinion multiple classes should be handled. It does not need to be this way if you feel like it doesn't match your plans. |
In readme there is a task in Road to superior development saying:
I have an idea. Godot for every
.gd
file has one main class and can have subclasses defined byclass
keyword. This really nicely match typescriptexport default
andexport
. This wayts2gd
will have an easy way of telling if a class in godot should be generated asclass_name SomeClass
orclass SomeClass:
. @johnfn what do you think about it?See #61 for proof of concept.
The text was updated successfully, but these errors were encountered: