This is the mail archive of the frysk@sourceware.org mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

Attachment: signature.asc
Description: This is a digitally signed message part


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]