From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10285 invoked by alias); 19 Jun 2007 21:58:11 -0000 Received: (qmail 10273 invoked by uid 22791); 19 Jun 2007 21:58:11 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 19 Jun 2007 21:58:09 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.1/8.13.1) with ESMTP id l5JLw5j2016319; Tue, 19 Jun 2007 17:58:05 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5JLw570018355; Tue, 19 Jun 2007 17:58:05 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l5JLw4Kd026410; Tue, 19 Jun 2007 17:58:04 -0400 Message-ID: <46785181.7030709@redhat.com> Date: Tue, 19 Jun 2007 22:30:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Mark Wielaard CC: frysk Subject: Re: frysk.proc.{ptrace,corefile} -> frysk.proc.{live,dead} References: <466FED51.3030804@redhat.com> <1181815036.4474.23.camel@dijkstra.wildebeest.org> <467149C9.8050509@redhat.com> <1181898053.4482.28.camel@dijkstra.wildebeest.org> <4672A4C3.4060009@redhat.com> <1181935650.4482.75.camel@dijkstra.wildebeest.org> <4676C8D3.90107@redhat.com> <1182192973.4534.90.camel@dijkstra.wildebeest.org> <467706B8.3050108@redhat.com> <1182241970.4459.21.camel@dijkstra.wildebeest.org> In-Reply-To: <1182241970.4459.21.camel@dijkstra.wildebeest.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q2/txt/msg00346.txt.bz2 Mark Wielaard wrote: > On Mon, 2007-06-18 at 19:29 -0400, Andrew Cagney wrote: > >>> 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. >>> >>> >> Sorry I don't follow, the but. This is good. >> > > Try showing that it is good and what the problem it is that it solves > with some concrete examples. An simple example of existing code and what > it should/could be might make things a lot more concrete and clear for > others to see which actual problem this solves. > A specific example that I mentioned previously was requestAddBLAH. live processes handle that, dead processes do not. > >> On Mon, 2007-06-18 at 18:27 -0400, Andrew Cagney wrote: >> Mark Wielaard wrote: >> >>> 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. >>> >>> >> Sorry, I don't follow, what do you think I am planning, and why do you >> think it is mixed? >> > > You don't make a clear distinction between on the one hand what exactly > you propose to move from the proc interfaces into the ptrace and core > implementation packages, and on the other hand the complete renaming of > the packages plus introduction of the new live and dead concepts. > Hardly, we're discussing end-goals. There's no need to describe in detail intermediate steps here. > I believe these new concepts of live and dead aren't really different > from the ptrace vs core distinction we have now. And if so then renaming > everything doesn't solve any actual problem, but just introduces random > change. But your examples don't make this clear to me. > Could there be confusion between a attribute such as liveness with an implementation choice such as ptrace. Not unlike how Collection is the super object, List is a refinement, and ArrayList is a specific implementation choice. > My proposal is that you first describe the separation of interface and > implementation between proc, ptrace and core, and then if we have a good > separation between interface packages and implementation packages then > you introduce the live and dead property concepts based on that. > And the way we do that is with the code. If I don't like the results i'll fix them. Andrew