Color type is now a `class` instead of `struct`

I have been back and forth on this one, but it is still a large breaking change that will affect users. Maybe. I am not sure exactly how this affects all the code when recompiled, but it is different.

This will matter though when there are new null ref exceptions popping up, but hopefully tooling can aid with that.

Most frameworks are structs - except for iOS - and this may be unexpected.

@jonlipsky did mention that he noticed some perf improvements with TouchDraw, but this might need a check on say Android with the GC. It may be that it is fine and the GC is OK and that copying structs is more expensive.

@Clancey mentions a nicer reading:

var foo = color?.ToNative() ?? defaultColor
// vs
var foo = color == Color.Default ? defaultColor : color.ToNative()

This is true, but it is also the same with Color? as a nullable.

This also relates to #57 where there is no longer a Default “color” and null is used.

Relates to parent issue: #58

[hartez]

Even with nullable structs, the code won’t be clean. You still need to check if it is default value. So the nullable struct is even uglier.

That’s only if we decide to use a struct AND keep a Color.Default. If we remove Color.Default, make Color a struct, and go with the convention that cross-platform colors default to null, then we end up with your cleaner-looking code. E.g., if my cross-platform property is

public Color? MyColor { get; set; }

Then my translation to a native color looks something like

var color = Element.MyColor?.ToNative() ?? GetNativeDefaultColor();

Where GetNativeDefaultColor is doing the work of determining what “default” means given the control type, usage, current theme, etc.

[charlesroddie]

+1 should be a struct