Swift-ification of the API

[vojtamolda]

This bug is a variety of not-related thing's that share the common goal of making the API more aligned with Swift API Guidelines.

Full descriptions are below and here's a checklist to keep track of progress:

• [x] Bound check and wrap Angle values
• [x] Create sections in the Layout.swift file
• [x] Domesticate alien enums with a .true, .false and .none cases
• [x] Make Layout.xAxis and yAxis assignable to each other (#8)

[vojtamolda]

Bound check and wrap Angle values

Description of the Angle struct in the Plotly schema assumes that the value is between -180 and +180 degrees. Swift implementation should ensure it's not accidentaly violated.

[vojtamolda]

Create sections in the Layout.swift file

Layout.swift is currently a gigantic file with ~10k lines. There's already some // MARK: - Section comments near the beginning of the file but later on the navigation becomes confusing. The section comments to simplify the navigation by creating horizontal bars and titles in XCode's Jump Bar.

[vojtamolda]

Domesticate alien enums with a .true, .false and .none cases

Some of the enumerated data types that can in JavaScript be enabled or disabled by setting the value to true/false feel strange when used in Swift. It would be nice to rename these to a more meaningful descriptions.

An enum containing several options and a .false would feel more consistent when .false is replaced with some other meaningful name as false in Swift is tied exclusively to boolean types.

For example the visible that is a member of ever trace suffers from this problem:

JavaScript	Swift
trace['visible'] = true	trace.visible = .true
trace['visible'] = false	trace.visible = .false
trace['visible'] = "legendonly"	trace.visible = .legendOnly

Another name that should be avoided is .none because this collides with the Optional type in the standard library. Under the hood Optionals are implemented as type-generic enums with .some and .none cases. Therefore using .none causes ambiguity errors when the variable in questions is instantiated as optional.

[vojtamolda]

Make Layout.xAxis and yAxis assignable to each other (#8)

Layout.XAxis and Layout.YAxis structs have identical purpose but apply to different coordinate axis of the figure. Currently, it's not possible to do a very natural assignment that achieves identical look of both axes:

var layout = Layout()
layout.xAxis = Layout.XAxis()
layout.yAxis = layout.xAxis

Figuring a way to enable sharing of these two data-types should fix the issue. There's a threshold of 3 uses for an object to be moved to the Shared.swift file and re-used. This strikes a reasonable balance between number of shared objects and the ability to assign identical objects to each other. This specific case is shared only twice and doesn't get over the threshold.

[vojtamolda]

Hooray!!!