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

[Andrew Cagney <cagney at redhat dot com>]

Mark,

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?   
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.

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.  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?

Andrew


Mark Wielaard wrote:
> On Fri, 2007-06-15 at 10:40 -0400, Andrew Cagney wrote:
>   
> > Mark Wielaard wrote:
> >     
> > > Yes, but my point is more that pre-mature refactoring at this point
> > > seems not a good idea. We don't seem to have all the information yet.
> > > But maybe you do have a clear picture already. I am trying to get an
> > > idea what we would really gain from it at this point. Which api users do
> > > you have in mind and what are they doing now through frysk.proc (or
> > > directly through frysk.proc.ptrace and frsyk.proc.core) that would be
> > > better modeled through the proposed properties-based package
> > > abstractions?
> > >   
> > >       
> > The user visible interface is frysk.proc, the rest is internal.
> >     
>
> OK, so you mean that for other parts of frysk there is just Task and
> Proc to deal with. LiveTask or DeadTask is just an implementation detail
> and an interface to the rest of the system? Then I am a little confused
> why you want these renames. If it is all about implementation details
> then the implementation names ptrace and core are much more appropriate.
>
>   
> > We could equally argue that the frysk.proc.ptrace refactoring was 
> > pre-mature.  For that we discussed, agreed, and then I implemented; the 
> > result while a step forward has clear problems; perhaps I could revert 
> > it.  This next step is along that path.
> >     
>
> No need to revert that, I do like the split between proc, proc.ptrace
> and proc.core and I do like to see that separation of public interfaces
> and implementation details. But I am truly not clear on the precise
> refactoring you are planning to do. It seems completely unnecessary to
> do a total rename for the refactoring of some methods into
> frysk.proc.ptrace and frysk.proc.core for the general frysk.proc
> classes. Could you give an concrete example that shows what you think
> needs to be done? Having an api prototype that you are thinking of will
> help review things for others.
>
> Thanks,
>
> Mark
>