> Ok. This is the hierarchical thing. In some DBMSs it would be a simple
> numeric RID (Record ID), but that doesn't assist in subtree searches.
> If you guarantee that for any object, a child-ID will never be re-used,
> you create a useful unique-for-all-time hierarchical ID.

Hmm. I hadn't thought of guaranteeing unique-for-all-time (i.e. maybe
not
across a database cleanup or something), but it's a thought.

> If it's not persistent, I'd leave it out. Any search operation should be
> able to take a context object and function from that.

Yeah, my approach will likely be "leave it out and put it in only if I
see a compelling reason."

> For persistent tree changes, the "flip parent and child" is a useful op.

Agreed. I haven't sketched out such operations yet.

> A sub-topic, or a note in a topic, which uses a value defined by
> its parent object, is experiencing value propagation rather than
> inheritance, since the child isn't derived from the parent through
> inheritance, but contained in a parent-child relationship.
>
> I note that you don't make any mention of actual inheritance. That
> simplifies things, but don't confuse the parant-child relationship
> with an inheritance one.

I wasn't using this in a strict OOP sense. After all, the word
"inheritance"
does predate computers by many centuries.

True, there's no subclassing going on. But if the child gets something
from the parent as a direct consequence of the parent-child
relationship,
that's a kind of inheritance. Just ask Gregor Mendel.

But I'm content with the term "propagation" as well.

> > It sounds like you're talking about multiple "views" of the data, is
> > that correct?
>
> It does give you that capability, but it's more than that. Essentially
> an observer has a topic of interest (what I call an aspect), and when
> looking at or for a target object, they see only those attributes (and
> children, if that's implemented) which are relevant to that topic.

I still don't see how that differs from a "view."

> > I'm halfway following this, though it's confusing. How would you
> > propose to store all this?
>
> I've been through many models for that, and the simplest is to just
> store each child item (a reference to a sub-topic or note, a value
> for a variable) with its "pertains-to" value, in a single place,
> serialised with the object, regardless of its relevance (aspect).

Then would you use a database for that or not? The columns of a table
are typically fixed and unvarying. (That's why my current code uses a
serialized hash for the user-defined metadata -- the field names are
not known in advance.)

> No. There's no *need* to scatter things. You could label an aspect such
> that all items which pertain to it are out-of-line (not stored directly
> in the parent object), which allows control of clustering, but it's not
> necessary. For example, you could choose to store all GUI layout
> values away from the objects to which they pertain... but it's not
> needed in a simple tool.

OK, I think part of my problem here is that I don't know much about
AOP.
Is that the kind of "aspect" you mean?

I am greatly appreciative of your interest in this, but I would want to
know how far your interest extends. No offense, but if I were going to
throw away my own model in favor of one I don't yet understand, I'd
need to know that you were going to contribute significant time and
code
to the project.

If you wish, I'll send you my latest code offline.


Hal