Define consistent specific naming to refer to the different types of types

[geekley]

I don't really like the term "Variant types", it's quite confusing. One could think: if everything can be a variant, isn't every type a "variant type"? Does "variant type" include objects or not? Does it include Variant itself too? IMO it would be clearer if Godot would consistently use "basic types" instead.

The term "class" can sometimes also be unclear if it refers only to Object and its subclasses or to everything.

---

Maybe it's a nitpick, but it might be a good idea to have specific meta-type term definitions like these for consistent and non-confusing naming across docs, etc. Also to categorize so one can refer to specific groups of related types together with a simple term. I thought I'd try listing suggestions here (all up for discussion).

This hierarchy could facilitate thinking about what should go where if making changes to the typing system of the engine.

So, this is how I see the Godot/GDScript type system in my head, and the terms I think fit best.

• "types": the most-generic term, to refer to any type below
  • "Variant" should refer only to Variant itself;
    "variant kind" could refer to the TYPE_* tag of a variant data structure
  • "classes" should refer only to Object and its sub-types
    • "scripts": user types (opposite is "engine types")
    • "engine classes": Object and sub-types, excluding scripts
  • "basic types" should be used to refer to all non-class types under Variant
    • "fundamental types": Nil and:
      • "primitive types": bool, int, float
      • String
    • "dimensional types": Color and the "spatial types":
      • "vector types": Vector*
      • "bounding types": Rect*, AABB
      • Quaternion, Basis, Transform*, Plane, Projection
    • "identification types":
      • RID
      • "designatory types": StringName and NodePath
    • "instruction types": Callable, Signal
    • "collection types": Packed*Array, Array, Dictionary, Array[T], Dictionary[T];
      all others (except Variant) are "atomic types"
  • "conceptual types" could refer to compile-time types not recognizable at runtime; (opposite is "implementation types")
    • void
    • enum/flag types (which become int at runtime)
    • potentially, if they're ever implemented in this compile-time-only manner:
      • interfaces, union types, structs, tuples, nullable types, etc

Some terms in addition to the hierarchy before:

• "parametric types" to refer to typed generics like Array[T], Dictionary[K, V], etc.
  • "parameterized types" if the type parameters are specified: Array[Quaternion], Dictionary[int, Node]
• "numeric types" meaning types with arithmetic operators: int, float and dimensional types
• "textual types" meaning String and designatory types
• "independent types" meaning all types fully contained in a variant data structure, without pointers (maybe except RID)

[tetrapod00]

I'm generally in favor of this kind of terminology standardization, but this seems like a lot of types of types to add specific terms for. How many of these groupings need to be referenced often in the docs? Some of the groups, like "bounding types", seem like they can be spelled out instead as "Rect2, Rect2i or AABB".

IMO the way to approach a problem like this is start with existing groupings that are mentioned often, and do not have an official term. Or look for terms that are already used, but inconsistently.

[Mickeon]

I sympathize with you on the inconsistent usage of "type" across the class reference, but I feel like the suggestions are overly thought-out.
For example, there's no need for "textual types" as for the most part it's better to refer to String directly.

"Object types", which should probably be "classes", are biggest offender, as not only it is inconsistent across the documentation, but also in the editor ("Node type" comes to mind).

Similarly, the concept of inheritance is also explained inconsistently and is potentially confusingly. Terms like "child class", "parent class", "object-derived", "inheriting", "inherited", etc. are used all over the class reference.

Sidenote, since you're spending the effort to categorise all Variant types, see also:

• Overhaul Variant Documentation godot#95487