haha, yes Ali. I was baffled to see so many layers of document model, for
really no practical advantage, only more confusion. Same with event
handling inside editor and IIRC ops model too. We should really be brave
and remove a bunch of unnecessary abstractions, and keep things simple.
That we should definitely adopt from js and python communities.
DoTheSimplestThingThatCouldPossiblyWork<http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWork>
On Wed, Jun 12, 2013 at 4:21 PM, Michael MacFadden <
michael.macfad...@gmail.com> wrote:
> 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
>
>
>
