Using class and +
instead of .
-chained builder for plot composition results in hard-to-use API
#191
Replies: 4 comments
-
One solution could be to let Kravis user to replace the default Kravis charting engine with Lets-Plot at the run-time and this way to continue to to use dot-notation API if he/she wish so. |
Beta Was this translation helpful? Give feedback.
-
The kravis code snippet was just meant for comparison to illustrate the differences in API readability. kravis serves a different imho very useful purpose (which is to provide a ggplot binding into kotlin), and I don't plan to change that. |
Beta Was this translation helpful? Give feedback.
-
I understand, my line of thought was that kravis could serve two purposes as that wouldn't require significant changes in the API or documentation. |
Beta Was this translation helpful? Give feedback.
-
Got it. Thanks for the clarification. I'd still be curious about general developer preference regarding . vs + builders in kotlin. To me + breathes too much R (where it was also realized by Hadley Wickham as a mistake - with %>% chaining as the correct modern alternative - but he did not want to change it in ggplot because of backward compatibility. |
Beta Was this translation helpful? Give feedback.
-
Because of operator precedence, the used class approach for geoms (such as geomBar) fails to provide a convenient syntax when showing a plot. It's a confusing mix of
.
,+
, as well as round and curly brackets:Example
By using a builder approach and using
.
for chaining (as we do in most other kotlin apis including kotlin-dataframe, a more user-friendly API experience would be possible.Beta Was this translation helpful? Give feedback.
All reactions