Handle recursion more gracefully

[kikito]

I mean seriously: basing myself on depth only is a half-baked solution.

(Also, need to think of synonyms for "half-baked".)

[mebens]

You've probably thought of this already, but what you could do is this: if you get to the maximum depth, you then start another inspector on the table which is beyond the maximum depth. Example:

<1>{
  a = <2>{
    b = <3>{
      c = <4>{
        d = <5>
      }
    }
  }
}

<5>{
  a = 1
}

However, when this happens you'll probably need to place something like

----------------

above and below the contents, to signify an individual inspect call; or should this be done by the user?

[kikito]

Oh! I didn't notice this was still open.

I created this issue because I didn't like having to rely on {...} for solving recursion. Now that I've got the and

stuff done, this can be closed.

Regarding your comment, I don't quite like that. If the user needs to print d on that example, the simplest thing is increasing the depth (inspect(t, 5)). Another possibility is just inspecting t.a (inspect(t.a)). I consider these solutions are good enough; Adding more complexity isn't really what I want. If I were to change the way recursion is handled, I'd simply remove the second argument (now that we have the ids it's not that important any more).

But, as always, thanks for your comments!

mebens commented 13 years ago

Ah ok, I see the context now. With that said, I think it works pretty well the way it is.

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[mebens]

Ah ok, I see the context now. With that said, I think it works pretty well the way it is.