I think of subsets like this: (a b c (d e)) and I'll say there are two sets there and (d e) is a subset of (a b c d e)
I think I need to think:
(a b c d e) (d e)
(a b c d e)->(d e)
where -> is "has subset"
A tree isn't:
a
|---- b
| |- c
| |-- d
| |-- e
f---
- g
It's:
a b c d e f g
0->a
0->f
a->b
b->c
c->d
c->e
f->g
where -> is "has descendant"
since -> transitive, a->b b->c so, a->c
I mean I know that, but I didn't sink in like it just did. I have found it is hard to preserve the notion of a tree as that structure goes from context to context.
I typically use a tree container to structure that sort of information. One day I had this aha moment where I said, "Everything is a tree." Today I am saying, "Everything is a set of objects with relationships.
I don't so much have hierarchy as "paths".
In practicality, I think I am going to be able to better capitalize on this structure... and use generic programming to operate across the board on these guys.
That means that in the above example, I can write generic processes that operate on the object/relation structure so that one process can handle sets/subsets and parent/child etc.
It's nothing new, in fact it's older than dirt, or radical... just an aha for me.
The first debate in my head is how to generically handle specifying the relationship between elements. I think I need an "Id Manager".
No comments:
Post a Comment