From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8448 invoked by alias); 22 Dec 2011 11:48:49 -0000 Received: (qmail 8436 invoked by uid 22791); 22 Dec 2011 11:48:47 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 22 Dec 2011 11:48:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id F109B2BB45D; Thu, 22 Dec 2011 06:48:33 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id f2hWpHOKv+kh; Thu, 22 Dec 2011 06:48:33 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 7F3722BB45C; Thu, 22 Dec 2011 06:48:33 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 4702C145615; Thu, 22 Dec 2011 03:48:21 -0800 (PST) Date: Thu, 22 Dec 2011 12:53:00 -0000 From: Joel Brobecker To: Siva Chandra Cc: gdb-patches@sourceware.org Subject: Re: [RFC] A new command 'explore' Message-ID: <20111222114821.GT23376@adacore.com> References: <20111222051725.GO23376@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-12/txt/msg00782.txt.bz2 > I did have inheritance in my first implementation. But soon realized > that I am essentially implementing stateless functions. Hence, I > removed the inheritance, kept the classes, and made the functions > static (to imply that they are stateless). In fact, we need not have > the classes as well. Like you have noted in your penultimate sentence > above, this is really not an API for others to use. So, isn't an > abstract base class and inheritance an overkill for a Python > implementation here? It might be overkill indeed, but I find that this is the natural way to implement in Python. You may be right in your observation about stateless functions, but it seems to me that the net effect of this design change is that it made the code more difficult to approach and thus maintain. For instance, you have to infer that all the classes, which from a programatic point of view are indepdent, actually all need to implement a given interface (which one and the semantics of that interface are not documented either). That's where abstract classes and inheritance bring some value. In a way, this reminds me of the discussions I was having with Ada newbies a long time ago, telling them how they did C programing in Ada... It feels a little bit the same way here. Just my 2 cents, though. This is your code, it's self-contained and it does the job, so I am OK with whatever you decide. -- Joel