Thoughts about design decisions for this library

[mikaello]

• The original library is quite permissive, and it is possible to provide invalid values when creating TinyColor objects. E.g. creating a TinyColor object with invalid RGB-values:

  tinycolor({r:1000, g: -1000, b:1000}).toRgbString(); // rgb(255, 0, 255)

  In this library I have chosen to do some validation on the input values, and in this case would None be returned instead of an instance with values (255,0,255).

• Almost all the color modification functions (lighten, brighten, etc) have validation on the modification value provided (not the color-instance). These functions does only accepts values between 0 and 100, if you pass a value other than this, None is returned. Is this legit?

• Since you always end up with a option(t) when creating an color-instance (except when using TinyColor.random()), it is a lot of unpacking when you are using all the other functions which accepts only t. Is this ok?

• In the original library you could always provide just a string or an RGB-object (in addition to a TinyColor-object) for all the utility functions, in these bindings I have chosen to restrict the functions to only accept TinyColor-instances.

Any thoughts on these decisions?