Main Area and Open Discussion > General Software Discussion

RightNote version 3.0.0 released

<< < (6/8) > >>

PPLandry:
Most outliners, once you clone an item, will NOT distinguish anymore between the "original" and the "clones", whilst conceptually, there should be an (updatable) difference, and which I call "natural parent" and "adoptive parent" - name it as you like, but it's evident any item in a tree hierarchy should have a "natural/main context", and then, perhaps multiple, "additional contexts" - and be it only for avoidance-of-recursion reasons: btw, I mentioned this problem within a discussion of InfoQube in the outlinerswforum, where the developer of IQ, Pierre Paul Landry, suberbly said (I'm citing from memory), "IQ allows for recursion"... when in fact, recursion is a PROBLEM of IM, and which has to be avoided/contained, and certainly not a feature of IM (development illac ;-) ).
-peter.s (January 27, 2014, 09:40 AM)
--- End quote ---

Hi Peter,
re: natural Parent: Agreed: In InfoQube, an item has a "Main Parent" and any number of other parents. Users can change which item is considered the main parent. The "Main Parent" is used to show hierarchy in grids.

re: Recursion: Why do you see recursion as a problem for IM software. In InfoQube, it is a very useful feature. This ensures that items can be moved around in the hierarchy without limitations (only limitation: an item cannot be a child of itself)

HTH

Pierre
IQ Designer

tomos:
@peter.s
thanks for the clarifications.
God be with the days when Latin was learned in schools - I did a few months of it myself aged about 12, but moved on when I got a choice (probably more to do with the teacher than the language itself).


PS, I sent you a PM related to your off-topic comments.

peter.s:
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

PPLandry:
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. ;-)
-peter.s (January 27, 2014, 01:31 PM)
--- End quote ---

No special monitoring software... simply using Google !

- Could we have a (short, schematized, but nethertheless) real-life example of where recursion in IM would really be useful?
-peter.s (January 27, 2014, 01:31 PM)
--- End quote ---

In IQ, hierarchy is something that is added to items. It is sometimes shown, sometimes not. Closer to a hyperlink than to a disk folder structure.

Items exist in the database, like you and me exist on this earth. If a parent is deleted, its sub-items are not necessarily deleted. Same for you and me... if your father dies, you don't automatically die with him.

So items exist in the database. At any moment, you may want to show an item as a new child of another item. For whatever reason. Why prevent this for the sole reason that somewhere up the hierarchy chain, that item is also present ?

Another example is any good old web page. It may link to sub-pages, and these will typically link back to the main page. A nice convenience and something we don't even think about. The same can be done in IQ.

So, there are at least 2 cases where this is desirable: (1) The hierarchy is deep and (2) To bring a parent close to an item.

Regarding sloppy IM and programming, I believe that IM software should not constrain users.
If recursion is supported, it is certainly not because of laziness, but as a feature. Example of this: IQ support hierarchy equations (i.e. such as value=SUM(children)) and inheritance. Both of these require that recursion be handled correctly to ensure that one does not get into infinite loops !

HTH !

superboyac:
PPL long time!  Good hearing from you.

Navigation

[0] Message Index

[#] Next page

[*] Previous page