GDScript: Trait system design

[dalexeev]

• Add a Trait system for GDScript #6416
• Add Trait System to GDScript godot#97657
• GDScript: Add Trait System godot#107227

Here you can discuss various aspects of the trait system. Please use separate branches for different topics: implements vs uses, traits vs interfaces, etc.

[Meorge]

One thing I've thought a lot about for the trait system is the naming convention for traits. To fit the English-like readability of the rest of GDScript, I propose PascalCase adjectives. For example, a trait that allows a node to be interacted with could be called Interactable, or a trait that runs a method when shot by a bullet could be called Shootable. This makes trait conformance/usage checks read like English:

if some_node is Shootable:
    some_node.on_shot()  # on_shot() is a method on the Shootable trait

I know C# uses the I prefix for interfaces, and we could perhaps similarly use a T prefix for traits:

if some_node is TShootable:
    some_node.on_shot()

This looks a bit weirder to me personally, though, so I think I'd prefer the first option. Of course, if anyone has other ideas, please express those as well!

[SeremTitus]

I prefer the first one (Shootable) and the use of -able suffixes where applicable. I also suggest we consider having different syntax highlighting colors (perhaps different shades of the same color) for built-in types, class types, and trait types.

[Mickeon]

I would heavily recommend no prefixes of that sort. This kind of thing is very much not in the style of GDScript (and is frankly outdated, as modern IDEs and better naming conventions solve any possible ambiguity).

[hantaogo]

[Peelep]

with could be a possible option as well

class_name Player extends CharacterBody2D with Mover, Movable, Damageable

[lostminds]

In the definition row I think both with and is sort of assume they'll be used on a single row with class_name and extends. But just like you can currently write class_name and extends on separate rows (and in either order?) I think this also needs to be considered for the traits definition keyword. And written on a separate row I think something more descriptive could work better. Why not literally use traits to also communicate that this is what we call this sort of thing in GDScript.

For example:

class_name Player extends CharacterBody2D traits Mover, Movable, Damageable

class_name Player 
extends CharacterBody2D 
traits Mover, Movable, Damageable

[Meorge]

I agree, but I feel like the same could also be said for the extends keyword. traits seems to me like it could end up being confusing: trait SomeTrait means that a trait named SomeTrait is being defined, whereas traits SomeTrait would mean that the class is using the trait named SomeTrait...

What about a mix, like has_trait?

class_name Player
extends CharacterBody2D
has_trait Mover, Movable, Damageable

I suppose the plurality doesn't quite line up (and also wouldn't if it was has_traits with a single trait), but it's a bit more explicit about what the keyword does

[lostminds]

Ah, indeed, I didn't consider the possible confusion between trait in the trait definition file and traits for what such traits a class would use, you're right that those are a little too similar. To differentiate them, another option could be to keep traits and instead change trait, for example to trait_name to be consistent with class_name.

So then you'd have something like

trait_name MyTrait

<definition here>

class_name MyClass
extends Node
traits MyTrait, MyOtherTrait

<definition here>

Regarding the plural in traits I still like it as it hints at the key feature that you can have multiple traits, while you can only have one class_name or inherited class in extends.

[DaloLorn]

I liked uses, myself, but for the sake of broadening the list of options...

Perhaps includes might work? (I do conditionally prefer trait_name over trait, though, as long as it's meant to be an analogue to the global-scoped class_name and not the class-scoped class.)

[ydeltastar]

I see there are no VM changes in godotengine/godot#107227. Is the goal for it to be a runtime feature, or like Python's typing module, which is hints for editor features but has no runtime impact?

[dalexeev]

Yes, that was the original idea, George even wrote about it somewhere. This feature is mostly resolved at compile time, at runtime it only affects the is operator.

We also have some concerns about typed arrays/dictionaries. But since we don't have a unified type system and first-class types yet, we decided it would be better if this feature was not available for typed arrays/dictionaries than if we touched the core, outside the GDScript module.

[hydescarf]

I was thinking of unifying them all under a single word has, that can be meant for only traits & checking with it, just like is for classes.
Though possible confusions are the has() functions, or to newbies, the equivalent confusion of is with ==.

class_name CustomClass
has CustomTraits1, CustomTraits2

if CustomClass has CustomTraits1: # don't mix `is` with classes?
    pass

Or perhaps, the original uses.

class_name CustomClass
uses CustomTraits1, CustomTraits2

if CustomClass uses CustomTraits1:
    pass

[Mickeon]

has in Godot... often refers to "containing" something, be it a value, property, method, signal, etc. So I would avoid it for that alone.

[shanayyy]

Why not use impl like Rust?😂

class_name Character impl Movable, Damageable

[Meorge]

My recollection is that impl was one of the earliest suggestions, since traits overall are commonly associated with Rust, but people weren't a big fan of how it shortens the word, unlike the other keywords like class_name and extends.

We do have var instead of variable and func instead of function, so there is certainly precedent for keywords being shortened. Alternatively, I feel like implements, while a little long, wouldn't be too egregious since it's just written once at the top of the file:

class_name Character
extends CharacterBody2D
implements Movable, Damageable

[UnTabouret]

With the current implementation of traits, is it possible to statically type/type check for traits ?

var foo : Movable

if foo uses Movable:
    foo.move()

Also if yes, would the second example enable autocompletion for Movable properties and methods like the following would ?

if foo is MyClass:
    foo.method_of_myclass() #this will be autocompleted in the editor