Ali,
Thanks. I agree with this perspective. When I started working with the
codebase, the nested levels of interfaces and implementations made it
impossible to trace through the code. Personally it seemed like
abstraction for abstraction sake. Yes.. It made things fairly unit
testable, but maintainability was scarified in other ways.
~Michael
On 6/12/13 11:47 AM, "Ali Lown" <a...@lown.me.uk> wrote:
>> I agree. I think we need to look holistically at the code base. I
>> honestly don't know what the best approach is. It sounds easy to say,
>> let's just modularize it. I am not sure the current code base makes
>>that
>> possible in any meaningful way. The code is so abstract and
>>intertwined,
>> it may take MUCH longer to modularize the code than it would to start
>>over.
>> On the other hand, I am not sure that starting over is feasible either.
>> I
>> really don't know.
>
>This is why I think it would be better to just attack it with the
>delete key. There are only a few files that actually do work, so I
>don't think we need to abandon the existing code. Everything simply
>has several levels of interfaces which are completely unnecessary,
>just flattening the model library and removing the unused options
>(in-memory delta store, in-memory search store, no-op federation
>system!) would let us see the codebase in a much clearer light for
>(what I think should be) fairly minimal effort.
>
>(My example flattening case would be the ConversationX ->
>ObservableConversationX -> WaveletBasedConversationX pattern X={nil,
>Blip, Thread, View}. And there are similar things for the {Mutable,
>Observer, Readable}Document, etc.)
>
>Hopefully at that point, the code base is small enough (or we are
>better informed), so can see whether to simply abandon.
>
>Ali
