[Design] Re: [Chandler-dev] Reengineering stamping

[John Anderson]

Ted Leung wrote:
> [ in an effort to reduce the number of cross posts, I'm just replying 
> to chandler-dev, since this is more about the implementation than the 
> design, at least in my mind ]
>
> Alec Flett wrote:
>> I think part of the issue is that there are key differences between the
>> design and implementation of these relationships - from my perspective,
>> what jeffrey described is the domain model relationships and how they
>> might affect the implementation of the UI, and what you've described is
>> more about the design relationships and how you would design the UI to
>> model them.
>>
>> (and I think threads are orthogonal to the implementation details that
>> Jeffrey is trying to work out)
> +1
>>> I get 1(Identiy coupling) and 3 (Loose coupling), I see the point of 
>>> 2, though I'm not sure we need to address this use case in the 
>>> short-term. But I think there's a missing relationship type: Threads.
>>>
>>
>> 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.
Can someone summarize the implementation headaches with stamping as now 
implemented.
>>
>> In my mind, the crux of the matter is whether identity coupling is truly
>> necessary all the way down in the domain model.
> I think the answer to this question lies in whether we are a talking 
> about stamping as a UI/display characteristic or not.   For example, 
> when we share, we use the item cloud notion to mark out a bunch of 
> items that must be treated as a unit in order for sharing to work 
> correctly.   So if something is stamped in the end user/design sense, 
> what do we expect it's sharing behavior to be?   Another are where 
> this might matter is searching.   If you do a search/filtered 
> collection do you expect to see the rest of the stamped items in the 
> result of the search?
>>
>> If the intent of the design is to make it look like, for example, a
>> calendar event is on my task list, there are other ways to implement
>> that beyond the identity mapping that we currently do.
> Agreed.
>>
>> I think frankly, it would behoove us to separate out the design notion
>> of an "Item" from the implementation notion of an "Item" because when
>> you (Mimi) say "An Item should have these properties and behave this
>> way" we're trying to match that too exactly in the domain model. (though
>> there is some irony that many people correctly point out that a "design
>> Item" is usually composed of many "implementation Items")
> If we can do that without problems for sharing or searching, then I'd 
> agree with this.
>
>>>
>> 3. Loose coupling is simply having attributes on an item point to 
>> another item. ie. Jeffrey in the To: field points to a Contacts item 
>> for Jeffrey Harris.
>> In the design sense, this is absolutely true. In the implementation,
>> there is little or no distinction between Tight and Loose coupling
>> besides perhaps the name of an attribute (for instance, tightly coupled
>> items may simply be related because their "tightlyCoupled" attributes
>> point to one another and loosely coupled items use "looselyCoupled")
> 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.
>>
>> [and yes, those are terrible names.. and that may not even be the
>> "right" way to implement it]
>
> Using a naming convention is certainly one way of implementing it.  
> The usual problem with naming conventions is name clashes or 
> misspelling of names.
>
> On the whole, I'm in agreement with a lot that Jeffrey and Alec said, 
> but there are still some things that trouble me and I need some more 
> time to ponder.  I just wanted to add a few thoughts while I had them.
>
> Ted
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "chandler-dev" mailing list
> http://lists.osafoundation.org/mailman/listinfo/chandler-dev