Relocate Color8 and ColorN methods from @GDScript class to Color class

[aabmets]

Should functions of similar functionality not belong to the same class?

[akien-mga]

They cannot be in the Color class while providing Color8() and ColorN() sugar constructors. I'm not against merging their functionality into Color, but the API would have to be different, and I don't think we can have static methods on Color either, so it could be awkward:

var color = Color()
color.set_8bit(255, 255, 255, 0)
color.set_named("rubicon")

CC @bojidar-bg who implemented those IIRC.

[bojidar-bg]

ColorN(NAME) already exists as Color.NAME, while Color8 is there since the earliest days of Godot FOSS.

[aabmets]

So it's a documentation issue, not a code issue?

On Thu, 11 Jul 2019 at 13:45, Bojidar Marinov [email protected] wrote:

ColorN already exists as Color.NAME, while Color8 is there since the earliest days of Godot FOSS.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/30499?email_source=notifications&email_token=ABVAJRE5C6WUCGYSOIMRS2LP64FMFA5CNFSM4H7R6ZHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZWJV4I#issuecomment-510434033, or mute the thread https://github.com/notifications/unsubscribe-auth/ABVAJRGPYSFT5KLZCRNIXQLP64FMFANCNFSM4H7R6ZHA .

[Calinou]

Now that static methods can be bound to engine types in master, should this still be considered for 4.0? cc @vnen

[alazifk]

IMHO now in the future Color should get static Color.from_rgba8() anyway, analogous to Color.from_hsv(), Color.from_rgbe9995(). Then I see no reason to keep Color8(), also I am not a fan of having a function that looks like a constructor, speaking as someone who has gone a long time thinking there is a class Color8 that derives from Color.

[akien-mga]

The named colors were moved to a static method, but not Color8. Adding a from_rgba8 could still be done.