[4.0] Why aren't there more static methods for built-in types?

[MarcusElg]

4.0 added static methods for built in types so that you can call var c = Color.from_hsv(0.58, 0.5, 0.79, 0.8) for example. This however has only been applied to a handful of types. Wouldn't it make sense for it to be expanded to more classes such as File, Dictonary and JSON? Such as File.open which is a static function in most other languages

[Mickeon]

I think the simple answer to the question is that no one has committed the change(s) yet. I believe it was brought up more than once.

[MarcusElg]

Ok hopefully it can be implemented in 4.1

[theraot]

Yeah, we can have static methods in classes. I have come full circle on this.

I initially liked the idea of having - for example - static methods on File (In fact, I think there was a proposal or an issue, but I can't find it right now).

Then I began accepting it as an idiosyncrasy of Godot.

Afterwards I began thinking it might actually make it easy to have a kind of sandbox. To be clear, the sandbox idea is NOT to prevent people from messing with Godot or messing with a Godot game, or using a Godot game to mess with the player system. It is to allow the game to prevent script loaded from the file system (which are not distributed as executable) from messing with the game itself or the player system. That is: it is for mod support. I say that with this in mind: godotengine/godot#7753 (comment)

If the the script has to create a File or Directory object to be able to access the external file systems, then we have a single point where we can deny them access: creating objects of specific classes.

Proper support probably means to tie into ClassDB… We need a way to separate what is the main game and what is loaded from mods. We can use a second SceneTree for that (as long as nobody goes with the idea of adding a static method to SceneTree to get the main scene, giving a way out to the mods. I say that with this in mind: https://twitter.com/_eons/status/1496127269676404739).

Thus, we would have to tie ClassDB to the SceneTree... Yeah, no. It does not sound too great anymore. Which is why I haven't made a proposal for that. We should look for another way to do it.

At least we could parse scripts and look for class instantiation (including ClassDB.instantiate). Well, if we are doing that, we might as well look for access to any static member. So...

Yeah, we can have static methods in classes. I have come full circle on this.