On 10/26/16, 10:41 PM, "Harbs" <harbs.li...@gmail.com> wrote:
>Sure, components should try and validate their values, but client code is >not necessarily components, and it’s pretty easy to introduce a bug where >client code supplies a wrong value. IMO, if you are using typed ValueObjects you should do some validation when storing any value, not just colors, in the ValueObjects. > >I do a lot of loading of content programmatically. This includes things >like colors. The dynamic content does not cleanly fit into MXML and pure >components. Setting properties using client code is the norm. > >Are worried about the performance implications of an extra check? Every bit of code costs in CPU and download size. It all adds up gradually. And I'd bet there are a significant number of applications that don't need these checks in production. You are welcome to create ValidatingSolidColor if you really need it. > >In our case we had some code like this in our app: > > var fill:SolidColor = new SolidColor(0xFFFF0000, 1); > var stroke:SolidColorStroke = new > SolidColorStroke(0xFFFFFFFF,1, 1); > >The color value could just as easily have been a variable whose value is >determined at runtime. > >This code works in Flash because it supports argb. I took the easy way >out by simply rejecting argb values, but I guess we could break off the >alpha channel and set the alpha with that value. That sound like there are multiple possible solutions so there should be multiple classes, one for each solution. IIRC, CSS has RGB and RGBA types and we may need to support both properly. Maybe we need to find a way to introduce an RGB and RGBA type in an efficient way so you can strongly type your color handling code. IMO it is a bit of a hack to be using uint for a Color, but that's how Flash does it. -Alex
