How can I access ConfigFile `load` method in a subclass?

Question

I am trying to make a function-specific subclass of ConfigFile. This is the skeleton I started with:

User.gd:

extends ConfigFile

func _init():
    load_user()

func load_user():
    .load(Globals.USER_DATA_FILE)

func save_user():
    .save(Globals.USER_DATA_FILE)

However, I get an error Parser Error: Error parsing expression, misplaced: '.' on line 7:

    .load(Globals.USER_DATA_FILE)

If I comment that line out...

func load_user():
    pass # .load(Globals.USER_DATA_FILE)

then the script parses fine, including the .save(…) call, so I'm pretty sure this is something particular to the load method.

Is this a bug that I should report, or am I doing something wrong?

Thanks,
- Johnson

Answer 1

load is a global keyword, that's the reason it's breaking (preload and load)

take away the "." or change your functions names to just "load" and "save"

extends ConfigFile

func _init():
    load_user()

func load():
    .load(Globals.USER_DATA_FILE)

func save():
    .save(Globals.USER_DATA_FILE) 

The "." is used if you want to call a function but you've already defined a function of the same name.

So the reason ".save()" works is because there's a function below "save()"

The reason ".load()" doesn't work, is because there isn't a function below "load()"

ps. just taking about the "." with no letters or numbers to it's left.

I have no idea why the .save works thoough

Comments

If that's the reason then it is a bug indeed. The global "load" method does something completely different than the member function "load" in the ConfigFile class. And yes, there is a load function in the ConfigFile class.

Answer 2

There is a bug that prevents you from doing it the way you want.
Whenever the parser identifies the name of a global function it expects it to be a call to that very function.
You'll get similar errors if you try to write a member function called "load" or "log" or any other name of a global function.
You should report that error, but as there are simple workarounds I don't expect it to get a high priority.

The easiest workaround is adding the config file not as a base class but as a member variable. This code does basically the same as yours:

extends ConfigFile

var baseclass

func _init():
    baseclass = ConfigFile.new()
    load_user()

func load_user():
    baseclass.load("user://user.cfg")

func save_user():
    baseclass.save("user://user.cfg")

This may look like a dirty workaround, but in C++ e.g. the difference between a base class and the first member is basically just syntactic sugar. And if you look at the scene structure in Godot you'll see that the first node in the hierarchy is also the one that the scene inherits from (e.g. if your base node is a Sprite you'll start attached scripts with "extends Sprite").