From: Clifford Heath Date: 2005-07-22T08:40:56+09:00 Subject: Re: Refactoring Tycho API - Opinions wanted rubyhacker@gmail.com 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.