Do we need a Color class?

[SebastienGllmt]

This engine has its own color class but the standard library already has one provided in AWT. It seems like we're just copying its functionality since its uses are virtually the same. The only difference is getColor() is replaced by .getRGB().

[ghost]

1. why not?
2. it is more slim (afaik, ive looked at AWT's but its been a while)
3. we can do our own stuff with it if we want while we cant change AWT's

[SebastienGllmt]

You're adding a class to a project which does nothing but clutter it. Keeping that class in there is a classic example of YAGNI (http://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it). If you need to add something later, then create the class then and either add the new helper methods or extend the Color class.

[ghost]

cough EXTREME programming cough I see no reason to remove it. It allows us to add whatever we want to the Color class unlike AWT's and its got a lot less crap in it. Looking at AWT's it has JNI? For a color class? Overboard much?

[meyfa]

I feel like the Color class should be kept, because in my opinion working with an AWT class while using a completely different rendering/drawing library (the end user at least, not the engine itself of course) is a bit strange. If the engine offers its own Color class, then it feels more natural I think.

[TheCherno]

Sometimes it will be necessary to store the certain colour, and any operations applied to it in an actual object instance. When more features are added to this, it will make things much easier. Also there's no real reason not to have it.