Clarity on including modules in a GDScript

gigagiant

EDIT: solution in comments below. There is in fact a way to consiely import modules over that I was not aware of when I wrote this...

I found a huge pain point in GDScript that is seriously making me think twice about using Godot.

Good code is modular. It should be very fast and easy to import/include "modules" (i.e., other functions from other file) into your script. In Godot, they completely f***ed this up

Typescript:
import someFunction from './someFunction
Godot:

const SomeScript = preload("some_script.gd")
onready var some_script = DefaultManager.new()
var some_func = some_script.some_func

Look at how much more complex it is to import/include a module in gdscript than in typescript. Look at how much easier it is to read the code in Typescript. It literally takes three lines to import one function

gigagiant

My code was bad, so although this is still an issue, it's not an issue most of the time (thank god, I was losing my mind over this!)

GDScript is an object oriented language, and I was trying to use it like python or typescript (which are imperative languages), and that was my mistake.

The trick is that all your modules have to be contained within a class. You can change your class's name via class_name SomeClassName, and then use it in another script like SomeClassName.your_func(). This is done here: https://godottutorials.com/courses/introduction-to-gdscript/godot-tutorials-gdscript-20/#:~:text=A%20static%20class%20cannot%20access,any%20class%20members%20(variables).

I don't know if anybody else does this, but to me it makes sense to adopt some sort of naming convention for classes that are used functionally, i.e., as a mere container for your pure functions you export as modules. I can't find any conventions for this, so I might just put a double underscore before a class used as a container for functional modules, like __SomeCollectionOfPureFunctions

xyz

gigagiant Each *.gd script file is a class. All classes are available from all other classes. Speaking in Python terms they are all automatically "imported".

If you want to make a collection of standalone functions, make a named class and declare the functions static. They will now be available everywhere via the class namespace. No need to instantiate any objects:

class_name MyFunctions
extends Object

static func foo():
	print("FOO")

Call from any other class:

MyFunctions.foo()

gigagiant

xyz Although it would be nice to be able to use GDScript in a non-OOP way and just create functions without a corresponding class, I guess that it doesn't matter much at all in the end. I don't like OOP, but I also realize that in game development OOP has an edge over other types of programming, and so it's the standard.

xyz

gigagiant If all functions (and properties) in that class are qualified as static, there is practically no class defined in OO sense. The class_name then serves merely as a namespace, or module name if you prefer that term. So such "static classes" are de facto plain modules. The only drawback compared to Python is that you cannot get rid of the namespace when accessing them, i.e. there's no equivalent of from X import * that would import the whole other namespace into the current one.

retroshark

I’ve updated the discussion topic to something more appropriate and within the confines of the community rules.