Using class and + instead of .-chained builder for plot composition results in hard-to-use API

[holgerbrandl]

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

// letsplot
(df.letsPlot{ x = "status" } + geomBar ()).show()
            
// kravis for comparison
df.plot(x="status").geomBar().show()

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.

[alshan]

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.

[holgerbrandl]

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.

[alshan]

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.
However if it couldn't then perhaps some 3rd community project could emerge providing .-based API around Lets-Plot.

[holgerbrandl]

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.