Automatically code-(de)generated initializers of all traces currently accept a ridiculously large number of arguments. On average it's about 50. To make it even worse Swift requires that the arguments follow the same order as the definition. This is very inconvenient and leads to below-average user experience in comparison to other Swift libraries.
In this specific case, behavior similar Python's keyword arguments would be preferable but it would require a change to Swift that's way above my competence level. Automatic completion built into XCode that usually saves the day isn't all too helpful because the parameter list is truncated and doesn't fit the screen.
One way to reduce this friction surface is a simplified init(...) method that accepts only a handful of the most frequent parameters. The idea is similar to what convenience init(...) provides for classes.
For example, the Scatter trace could be created via a constructor that is understandable without a deep dive into the (at the moment non-existent) documentation:
My gut feel is that the reduced initializer covers about 70% of use cases. More complicated charts that require tweaking of other properties can be created by crating var and modifying the rest of the properties on the following lines in arbitrary ordering:
Automatically code-(de)generated initializers of all traces currently accept a ridiculously large number of arguments. On average it's about 50. To make it even worse Swift requires that the arguments follow the same order as the definition. This is very inconvenient and leads to below-average user experience in comparison to other Swift libraries.
In this specific case, behavior similar Python's keyword arguments would be preferable but it would require a change to Swift that's way above my competence level. Automatic completion built into XCode that usually saves the day isn't all too helpful because the parameter list is truncated and doesn't fit the screen.
One way to reduce this friction surface is a simplified
init(...)
method that accepts only a handful of the most frequent parameters. The idea is similar to what convenienceinit(...)
provides for classes.For example, the Scatter trace could be created via a constructor that is understandable without a deep dive into the (at the moment non-existent) documentation:
Especially to first time users, this looks much less intimidating than the full list of 46 parameters:
My gut feel is that the reduced initializer covers about 70% of use cases. More complicated charts that require tweaking of other properties can be created by crating
var
and modifying the rest of the properties on the following lines in arbitrary ordering: