I hate that color values are treated as R,G,B values instead of real objects. I have a suggestion on how it could be easily implemented in a way that is backwards compatible.
One of the beauties of Lua is how it treats objects, tables, and functions as “first class” values that you can assign and pass around. Using three separate values for color (r,g,b) defeats that great feature of Lua making colors extremely cumbersome to work with.
For example, I don’t want to hard-code color values into setFillColor. I want to have a local constant at the top of my file giving the color values. So right now I’m doing a lot of stuff like this:
[lua]backgroundColor = {r=80,g=255,b=200}
…
obj:setFillColor( backgroundColor[r], backgroundColor[g], backgroundColor[b]);[/lua]
Ugly ugly. Then there is the problem that I cannot query an existing object for its FillColor or StrokeColor.
What I propose is that Corona defines a Color Object (table), similar to what I use above. A Color is a table with keys “r”, “g”, b". Then instead of using the setFillColor method of an object, you could just add a fillColor PROPERTY to the object. Then you could do stuff like this:
[lua]backgroundColor = {r=80,g=255,b=200}
…
obj.fillColor = backgroundColor
obj.strokeColor = obj.fillColor[/lua]
This would also allow us to pass color values around in function arguments.
There is a file in the Code Repository that handles colors using a similar table structure.
In fact, you could even support something like:
[lua]obj.setFillColor( backgroundColor)[/lua]
since Lua can easily detect that you only provided a single argument instead of a full r,g,b,a list.
Think about what a pain it was to add support for the Alpha values. You had to go and add an additional arguments to setFillColor, setStrokeColor, etc. If you had properly implemented Colors as first-class table objects in the first place, this would have been a lot easier.
This would also allow developers to use their own color models, such as CMYK instead of RGB, making Corona more flexible in the future. Hardcoding RGB values is just not the way to go. [import]uid: 12529 topic_id: 5890 reply_id: 305890[/import]