Re: Refactoring Tycho API - Opinions wanted

[e-mail] wrote:
> Hmm. I hadn't thought of guaranteeing unique-for-all-time

The benefit is that you can have references from one Tycho database
to another, and where the databases are separately updated, the
references will still be valid as long as the referenced object
still exists. Likewise for any internal references, you don't have
to go searching to update and delete them when the referenced object
gets changed.

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

Understand. It's just that parent-child is a common description
of an aggregation relationship (no inheritance), and "inheritance"
is applied to classification hierarchies (quite unlike the parent-
child relationships the term implies). Typical non-intuitive semantic
disjunctions. Computer scientists seem to specialize in fouling up
language this way :-(.

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

The reason I use propagation is that I don't know of any language
where *values* get inherited. It's always traits - variables and
methods. My Aspect Definition Language has value inheritance, but
I restrict myself to using inheritance in the bogus O-O way,
applying it to the classification hierarchy as others do. That
leaves me unable to use the same term where a child uses a value
defined by its parent, so I use the term "propagation" for that :-).

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

To me, a view is formed by a restructuring or simplification of the
subject material that is *externally applied* to the material. In
aspect-oriented modelling, the structure is built into the material.
A variable/value applies to an object *and* pertains to an aspect,
intrinsically, not because some viewer wants to see it that way.

> 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.)

Yes, it's a problem to map aspect-oriented data to a database for this
reason. I started a project in 1987 to build an aspect-oriented database
to solve this, but I never finished it. So now I'm where you are, having
to choose between:
* using a database with a meta-schema - so you can't "see" the true
   schema :-(,
* mapping the aspect model to a relational schema - somewhat inflexible,
* abandoning the idea of using a transactional store at all, and just
   stashing the data into a data file (like XML, YAML, etc).
Not a good set of alternatives, I admit.

> 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?

It's related, but AOP is not it. In fact I think AOP is pretty
mis-guided. It addresses real problems, but in the wrong way.
Aspect-oriented modelling is my solution to that.

> 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.

Understand. I think you'll find that to adopt some of the ideas I'm
suggesting is quite simple and doesn't require much change from what
you were going to do anyway. At present I can't say whether I'll be
able to contribute to Tycho, because I'm awaiting the go-ahead (in the
form of an IP disclaimer from my employer) on a much more ambitious 
project. If that comes through, I'll be able to demonstrate what I'm
on about, but not through Tycho.