From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 124107 invoked by alias); 1 Nov 2019 21:01:25 -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 124097 invoked by uid 89); 1 Nov 2019 21:01:24 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=difficulty, wish X-HELO: mail-wr1-f66.google.com Received: from mail-wr1-f66.google.com (HELO mail-wr1-f66.google.com) (209.85.221.66) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 01 Nov 2019 21:01:23 +0000 Received: by mail-wr1-f66.google.com with SMTP id t1so4914896wrv.4 for ; Fri, 01 Nov 2019 14:01:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo-io.20150623.gappssmtp.com; s=20150623; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LPPWjpqXXJdTBIrIo2X96G7Zua9oOxs7zPWylhAhH9k=; b=xCwB+xn6d5Kdxhp+WceXvvtWD7ldeZnOeYzagD0jPfPVLLrCOuVcbyimjtGqud9tZp Mqd1Wmzi9mo3NQ09bkkipriHitGo4lcUDdQFjAn4mkyM0WpnCtsl2Zis6Vam/9OkolOD LAbNGy1wAxXBdPumpVY/qYIyO13+HxhX9CiPK9d2PLxnopEWSWJNaSwluZEV02Y0VlZk UuzctrzvDumTrphza/NdS2iB6cpi8SZ0jHsoY7u8SCEW6zc9tC48lxfKDdKXbhKNjSav y9PGoa9CBnGswA3tXpUndr1rNxhUVct/iglq1CwxySG5fDe0wT28JDEouvDvHYsQCQ5g dpVQ== Return-Path: Received: from [192.168.0.108] (cpc91242-cmbg18-2-0-cust276.5-4.cable.virginm.net. [82.8.129.21]) by smtp.gmail.com with ESMTPSA id 76sm14319400wma.0.2019.11.01.14.01.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Nov 2019 14:01:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\)) Subject: Re: [PATCH v2] Add a way to preserve overridden GDB commands for later invocation From: Marco Barisione In-Reply-To: <87wocj1k3y.fsf@tromey.com> Date: Fri, 01 Nov 2019 21:01:00 -0000 Cc: gdb-patches@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <2E9BBFD2-6643-4958-AF6B-FFC974FFF479@undo.io> References: <20191028133234.319-1-mbarisione@undo.io> <20191101085449.28493-1-mbarisione@undo.io> <87wocj1k3y.fsf@tromey.com> To: Tom Tromey X-IsSubscribed: yes X-SW-Source: 2019-11/txt/msg00043.txt.bz2 On 1 Nov 2019, at 19:18, Tom Tromey wrote: >>>>>> "Marco" =3D=3D Marco Barisione writes: > Could you say what unexpected behavioural changes you would anticipate? > I tend to think it would be clearer if all commands were treated > identically. >=20 > Is there some implementation difficulty doing it? Or was it just that > you didn't think it was useful? I was mainly worried about changing the behaviour in ways which could be unexpected. For instance, an instance of gdb.Command may end up living lon= ger than expected. Another thing is that a command which was written before this patch may not= be using the original implementation just because it was not possible before, = so block a further command from accessing it as well. See the example later in the email. If you don't think these are problems I'm happy to simplify the code. > In this model, if a Python command overrides a built-in command, and > then is itself overridden, can the new command still access the > underlying built-in command? Let's say you override delete. Let's call the first class overriding it DeleteCommand1 and the second DeleteCommand2. If DeleteCommand1 didn't use preserve_when_overridden then DeleteCommand2.invoke_overridden will just call the original delete. If DeleteCommand1 was preserved, then DeleteCommand2.invoke_overridden will call DeleteCommand1.invoke. At this point DeleteCommand1 may just do whatever it needs on its own, or call its own invoke_overridden method which will call the original delete command. DeleteCommand2 has not way to invoke the original delete command directly. This is partly because I'm not sure how I would expose this in a nice way, but mainly because I don't want commands to accidentally skip some previous implementation by accident. For instance, if we had an invoke_original method, then DeleteCommand2 could call that and skip DeleteCommand1. > What happens in the weird case that you have a command alias X, then > override X, and then override the thing that the original X was aliased > to? Will calling the overridden X do the right thing? Really I'm > wondering if that crashes -- maybe a counter-argument to my wish for > generality is that aliases should not be overridden. Oh right, aliases are treated a bit differently and I didn't think of testing that. I should add a test and see. --=20 Marco Barisione