class_name won't work on built-in scripts

[mateusfccp]

Godot version:
Godot 3.1 build 8698876

OS/device including version:
Arch Linux

Issue description:
When a Script.gd has a class_name, it will be reckognized by the engine and can be used later. However, if a script built-in on a Scene has a class_name, other scripts won't reckognize it.

Steps to reproduce:

1. Create a new scene.
2. Attach a script to it, and mark the option "Built-in" to be "On"
3. On the content of the script, name it with class_name. Example:

extends Node
class_name Item

func _ready():
    pass

4. Create a new script.
5. Extends it with the newly created built-in script.

extends Item

6. An error will be thrown: error(1, 20): Unknown class: 'Item'

Minimal reproduction project:
Built-In class_name.zip

In this project, there's both a Built-in (class_name BuiltinItem) and a not built-in (class_name NotBuiltinItem) scripts. Open the Script.gd file, you will see the error described above. If you change the extension to NotBuiltinItem, the error will disappear.

[vnen]

This is expected. I don't think class_name makes sense for built-in scripts.

[mateusfccp]

This is expected. I don't think class_name makes sense for built-in scripts.

I think it does. Sometimes I have a scene, that will be extended by other scenes and I want to check in code if this other scene extends the first one. I do this using class_name, but I have to separate the script from the scene in a new .gd file before. I do this all the time, as I use built-in scripts for my scenes by default, and only separate it when need to use class_name.

[QbieShay]

I think that built in scripts should not be used much. I use them only if I need to quickly test something. There have been some issues reported about their different behaviour and I am beginning to question how worth it is to keep them.

[mateusfccp]

There have been some issues reported about their different behaviour and I am beginning to question how worth it is to keep them.

Well, that's for a another issue. I like them and just won't use them when not possible (the only case when it's not possible for me is the class_name case) because it keeps my project more organized. It's cleaner to have a Something.tscn than both Something.tscn and Something.gd linked to it.

[QbieShay]

I think it is easy to lose track of where is what when the project grows, but this is just my opinion.

@vnen I believe that if builtin scripts are some sort of second class citizens, then it should be clearly stated somewhere.

[vnen]

It's cleaner to have a Something.tscn than both Something.tscn and Something.gd linked to it.

That's quite subjective and I would argue the other way: it's cleaner to separate the concerns. When you look at the filesystem it's clear that that scene has a script. The same way it's not good to embed images in a scene. I find it also helpful when I need to edit a script without the Godot editor.

Sometimes I have a scene, that will be extended by other scenes and I want to check in code if this other scene extends the first one. I do this using class_name, but I have to separate the script from the scene in a new .gd file before.

How did you do this before class_name? I don't think you could ever extend a built-in script.

I believe that if builtin scripts are some sort of second class citizens, then it should be clearly stated somewhere.

Probably. Honestly, if it were up to me I would forbid built-in scripts, they give more headaches than it's worth.

[PetePete1984]

Splitting scripts and scene files is also miles better for use with VCS. A Scene file usually is "mature" pretty quickly in regards to the components inside of it, but the scripts will evolve more often over the lifetime of a project.

[mateusfccp]

How did you do this before class_name? I don't think you could ever extend a built-in script.

I didn't, I use Godot since it has class_name and it is a so basic feature I don't even know how people did without it.

[jahd2602]

This is expected. I don't think class_name makes sense for built-in scripts.

If that is the case, then implementing a warning/error when typing that should be enough to close this issue.

[MyNameIsDabin]

As I continued to use altitude, I discovered some of the disadvantages of built-in scripts and finally decided that it was advantageous to have separate scenes and GDScript files. The reasons are as follows:

1. The built-in script cannot find a type in another script when using the keyword class_name.

If you use the keyword class_name with the embedded script in the scene, no other scripts can find the class name.

2. The version control system is a little bit more cumbersome to resolve the conflict.

It's built-in the scene. If there is a conflict on the versioning system, you must open and modify the thin file. Of course, the altitude is so designed to be very good for versioning that the internal structure of the thin file is not complicated. But it's a little bit more cumbersome compared to just modifying the GDScript separately. For example, if you want to modify a conflict in an external editor, such as VSCode , the embedded script portion does not apply to Synctax.

3. The built-in script is difficult to recycle.

Because you depend on the scene, you eventually have to save the script as an external file if you want to import it from another It's not as rare as I thought it would be.