[Vague limits of morphic]

two answers -
1. Theoretically, and IMO, and an important part of your job is to bring
us there, Morphic, as a framework, should have pretty clear limits.
There should be a set of classes that are all needed for a Morphic UI,
but don't depend on anything. And everything else is an extension.
Obviously applications (Alice Games) are not in. Even Menus, PLMs and
friends are probably extensions, in the sense that they don't are not
intrinsically needed by morphic (just by many applications).
My theory about how to trace and solve this kind of issue is that the
unclear borders are marked by cycles - when the framework references
applications that use it, that's pathological. So it should be useful to
find the cycles and cut them. That's what SpaghettiTracer does. If you
want to give it a shot, let me know and I'll explain more.

2. On another level (where do your patches go, when you're not changing
big structure yourself), you should keep tabs on removals and other
ongoing refactorings that have a Morphic aspect (even Celeste, to a
small extent), and when you affect something that went into the module,
as people have said, send the patches to the maintainers. IOW, try to
use the de facto package borders.

Daniel

diegogomezdeck at consultar.com wrote:
> > Julian Fitzell <julian at beta4.com> wrote:
> >> goran.krampe at bluefish.se wrote:
> >> > <diegogomezdeck at consultar.com> wrote:
> >> >>One obvious but notSooGood solution is to create a small piece of
> >> >>code that remove from out changes all the modifications we made to
> >> >>the just-removed classes.  The dark point with these aproach is
> >> >>we'll lose a lot of cleaning.
> >> >
> >> > But wait - shouldn't your changes simply be routed to the maintainer
> >> > of said packages?
> >> > Then they can update their packages and the rest is released on the
> >> > update stream.
> >>
> >> Yes, presumably if you file in the replacement package with DVS, then
> >> any changes you make will go to those packages and then you can send
> >> diffs of the DVS packages to the maintainers.
> >
> > Right! If they use DVS of course. But that's true - sounds rather easy.
> > As it should be.
> 
> I'm not sure how to it'll work.
> 
> I see a (big?) problem: What is Morphic? It's not so easy to define wich
> parts of the image is Morphic or not.  It's not only a problem of "big-
> mess", morphic is an ortogonal concept to a lot of packages.
> 
> IMO, it's really difficult to define the borders between Morphic and
> TheRest.
> 
> Can you give me more details how you think DVS can help here?
> 
> Cheers,
> 
> Diego