From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16622 invoked by alias); 9 Jan 2014 19:01:30 -0000 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 Received: (qmail 16610 invoked by uid 89); 9 Jan 2014 19:01:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ve0-f179.google.com Received: from mail-ve0-f179.google.com (HELO mail-ve0-f179.google.com) (209.85.128.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 09 Jan 2014 19:01:29 +0000 Received: by mail-ve0-f179.google.com with SMTP id jw12so2745797veb.38 for ; Thu, 09 Jan 2014 11:01:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=nsOz/6nLG5ZtlLOM4iksW7DtvqedRoVpcKp+pyhoBB4=; b=KAyBRnWW3kgagHYBa9FU6EPQgp3Dqo+oQt6pZTz/Rde0kJqhrmqYvBNSXi+qH8vXyf KbP0B5ASE4TjLmQdPJBVUCUdnGSUL9f/886MekxjDdme20IQwqWvpxIESoh3PpLEgGEp WP0YVFcDh4YihNf2Byv9sykOPezCX0AKX1As62TMZlDl63q2x22BuhBQBhUQuG8+1f/O g+WWKlj5C8qxzuNAWMNPk9n6A7wJp2Yb7qtqqZ6daNQY/EjJAEz6zsljB+78+T6Cl6wX karUm5/tgvknDc89MzdlDr/CVeAUyL+jgrFSYZmJJV+1Ef77TVIEobZI8nHpK4E6DRwQ B7ag== X-Gm-Message-State: ALoCoQkbdQMIKoCykz1ANWJwNlU3uXxNUKlZ91kEbENxRLRCkK8qdbpgoUi/pt/YwAkpKsA3pP2367WBbPINmOewae+Ql6m9joXKkcd9fbI+1SA7aOePrhPhDDhSiX+m0pwVMj+rI5aV17qU9Lwd6cvLRWYA2aaeXVLr+PQeVoIqbC3uTkAZCfaGbwWVIqPvs4/jUxgDxfSlRAhRLFq7meYMcJTLn2S7Dg== MIME-Version: 1.0 X-Received: by 10.58.127.103 with SMTP id nf7mr2284940veb.76.1389294086915; Thu, 09 Jan 2014 11:01:26 -0800 (PST) Received: by 10.52.116.174 with HTTP; Thu, 9 Jan 2014 11:01:26 -0800 (PST) In-Reply-To: References: Date: Thu, 09 Jan 2014 19:01:00 -0000 Message-ID: Subject: Re: [PATCH] Debug Methods in GDB Python From: Doug Evans To: Siva Chandra Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-01/txt/msg00255.txt.bz2 On Tue, Jan 7, 2014 at 4:48 PM, Siva Chandra wrote: > I am assuming you have not prescribed anything here, but are only > presenting pros of doing things in a certain way. I am also assuming > that you are waiting for others to chime in with their views. For the most part, correct. Though I haven't seen a compelling argument to be different than how pretty-printers do things. > On Fri, Jan 3, 2014 at 10:52 AM, Doug Evans wrote: >> I like having the object gdb calls to do the lookup return another >> object that gdb calls to implement the functionality. >> >> 1) It supports more flexibility in how the user can organize things >> (e.g., one "lookup" object can handle different "worker" objects). > > For doing such things, I had a design like this in mind: We setup up a > hierarchy of DebugMethod classes. The base class only does type and > method matching. The derived concrete classes extend the base class by > adding arg matching and the method invocation. This way, 'lookup' and > 'worker' functionalities are separated code wise but still > encapsulated in a single DebugMethod object. > >> 2) The worker object can obtain state at runtime (it is constructed at >> lookup time). > > This can be done on a single object by providing a setter? But if this single object isn't constructed at lookup time this would be modifying, essentially, global state. [Maybe I'm misunderstanding.]