Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead}

[Mark Wielaard <mark@klomp.org>]

On Mon, 2007-06-18 at 14:02 -0400, Andrew Cagney wrote:
> Reading between the lines I suspect your concern here isn't so much 
> about this specific change but about the rate of change in general?

No, more the rate of changes I don't really understand the why of. I
like to have more design discussion on the list so we all know why and
what changes are proposed and being worked on.

> Remember Frysk as a project is relatively free flowing when it comes to 
> its code and refactoring.  We don't spend days or weeks musing over 
> choices, or trying to design perfection.  Instead we design for todays 
> problem and let tomorrows developers re-design for their future.  This 
> gives us much flexibility while while ensuring that we are focused on 
> real rather than hypothetical needs.

That is good. But what I am missing is the actual problem statement.
What exactly isn't possible today and what is possible tomorrow after
such a change is made. My concern is that some of this is just
refactoring for refactorings sake. That is why I ask the why and what
questions.

> Here I implemented frysk.proc.ptrace, and contrary to what you assert, 
> it is a mess.  It forced the exposure of numerous public variables in 
> frysk.proc.Task.

I don't believe I assert that at all. The split of the proc interface
and the proc.ptrace and proc.core implementation refactoring is not
complete though if it exposes things in the interfaces that should be in
the implementation packages.

>   By instead re-aligning the sub-packages to focus on 
> "liveness" and refactor all "liveness" variables and code out of 
> frysk.proc and into frysk.proc.live.LiveTask (e.g., implementation of 
> requestAddObserver blah) I can move forward and fix this problem.
>
> Can we do that?

We can certainly refactor the proc interfaces and implementation
subpackages. But you are mixing two things in your plan. The renaming of
existing packages and classes (which I don't see any benefit of) and
exposing flaws in of the refactoring of the proc, proc.ptrace and
proc.core code because there is a clear separation between interface and
implementation.

Cheers,

Mark