At 04:30 PM 3/15/2006 -0800, Ted Leung wrote:
Alec Flett wrote:
At the moment, we've tightly matched the design relationships (i.e.
"stamping") all the way down through the domain model (i.e. so
"stamping" == "identity") and I think that is why there has been so much
resistance to stamping from those implementing it. The implementation of
stamping-as-kind-morphing has caused us some serious headaches and the
0.7+ plans are looking even worse as long as we continue with our
current implementation. I'm sure it made sense at the time, but I think
the design of the product has become more concrete and it doesn't make
sense anymore.
There might be other ways to preserve item identity if that was what we
wanted, such as Annotations. However, I think I agree that the kind
morphing that we are doing now is problematic.
Ironically, I see the Annotation approach and the "universal attributes"
approach I prototyped in Spike, as both being attempts to *better* match
the design relationships in the UI in the implementation model than the
kind-morphing approach.
You see, when you stamp something, you're not really changing the kind of
the item, any more than sticking a note on your calendar changes the nature
of the thing you're scheduling. So, the annotation and universal-attribute
models simply make it possible for you to *record additional facts about
something*, which is all that stamping is - recording a set of related
facts about a thing that is not truly changing in its nature.
In the implementation we have 3 mechanisms, possibly 4, available for
relating items.
1. attributes whose values are scalars
2. attributes whose values are other items
3. kind morphing
4. annotations
I think it's pretty clear that there are problems with using #3 to
implement the stamping design that Mimi is after. Since all problems in
CS can be solved with indirection, I'm pretty sure there's a way to solve
our problems using #2, but I have a feeling this might be more complicated
than we think it will be. Since #4 works on a per class basis, it also
feels like the wrong solution, since stamps aren't applied to all items of
a kind/class.
This is where I disagree; annotations are simply facts recorded about an
item. I'm not saying that means we *have* to use annotations, just that I
don't think that your feeling should stop us. ;) Note that the purpose of
annotations is to add the *ability* to record additional facts about some
kind of item. It is not a *requirement* to record them. In a relational
system, it would be like adding an extra table that doesn't need to have
rows for everything in the base table. It is normal and expected that the
presence of an annotation does not require recording information for that
annotation on all items of that kind. In fact, it should be an error for
an annotation to define required fields.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "chandler-dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/chandler-dev
