nested function definitions

[moodymudskipper]

This is frustrating to investigate, as a good part of the logic is in functions defined at the start.

funflow::view_flow(tools::Rd2ex)

They could be boxed, the function call and args without body would be on top in an oval shape with arrow upward (maybe see if we can find another arrow to mean "assign", else we'll use an "assign" label" next to the arrow). Then the body would be a flow diagram.

This box is probably more useful that the casewhen box

[moodymudskipper]

maybe there need to be a min "length" before unwrapping a function, of0 <- function(...) of1(paste0(...)) should stay as a simple call for instance (I think).

Maybe at first just unwrap multiline functons.

[moodymudskipper]

This example is good because we have deep nesting, as render renderDont

[moodymudskipper]

Nesting will be a mess, we can do much better and much simpler.

In funflow::view_flow(tools::Rd2ex) we see that we have a function definition in the 1st box.

funflow already uses a printing method (we don't View through a side effect). Thus we can use a subsetting method too, we could use [ with two arguments :

• first arg is box number
• 2nd arg is number of encountered function as we go through the parse tree looking for a function call, it's 1 by default, and it's not that often that we have several function definitions in a box
• if the def is attached to foo <-, we use it in the view, if not we can call it *anonymous fun* or smth similar

In our example we'd have :

• funflow::view_flow(tools::Rd2ex)[1] to show the 1st and unique function in box 1
• funflow::view_flow(tools::Rd2ex)[1][n] to show nested function, with n easily visible by printing funflow::view_flow(tools::Rd2ex)[1]

[moodymudskipper]

we chose another way but the feature is there

[github-actions[bot]]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.