Hi tomos,
You see, Pierre Paul has got sw that for any mention of his prog, wherever that might be, he's informed of it, and pronto! Neville should have similar, so no prob for discussing sw within threads named for different sw. ;-)
Hi Pierre Paul,
I tried to discuss recursion some months ago with you, but you didn't answer.
Let's just continue our discussion over there.
For the casual reader here:
- whenever recursion occurs, you must cut it off on export/print (and the routine could add some info there re the cut, e.g. reference to the item number ("e.g. 3.2.6.3.2") in the exported subtree
- data replication (e.g. a cloned heading with some general info, at several places in the hierarchy) is not recursion (and thus is without prob)
- I've never seen any IMS in which recursion would have been "advisable", let alone "necessary" for any of its content, hence:
- You could even implement a routine that will prevent recursion, your data construct only gaining in clarity by this
- We're speaking of IM here, not of code libraries
- But even those, incl. their recursive parts, can be put in a non-recursive tree structure
- In fact, we're discussing main frame spaghetti code for information... but then came Jean-Dominique Warnier...
- And what was missing in his system, we do it by cross-referencing
- Could we have a (short, schematized, but nethertheless) real-life example of where recursion in IM would really be useful?
- Sloppy programming has been exterminated; why incite "information managers" to do sloppy IM?
My points for IM are:
1 - Recursion can (but must) be handled when it occurs
2 - Recursion can be prevented (as can "go to")
3 - Recursion should be avoided for clarity reasons
4 - I'm open to rethink point 3 if I'm given a real-life example where recursion might be helpful
