From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5064 invoked by alias); 16 Dec 2013 07:48:11 -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 5048 invoked by uid 89); 16 Dec 2013 07:48:09 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-wg0-f53.google.com Received: from mail-wg0-f53.google.com (HELO mail-wg0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 16 Dec 2013 07:48:08 +0000 Received: by mail-wg0-f53.google.com with SMTP id k14so4275502wgh.32 for ; Sun, 15 Dec 2013 23:48:05 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.180.206.11 with SMTP id lk11mr9827813wic.16.1387180085075; Sun, 15 Dec 2013 23:48:05 -0800 (PST) Received: by 10.194.123.4 with HTTP; Sun, 15 Dec 2013 23:48:05 -0800 (PST) In-Reply-To: <871u1j2ldi.fsf@fleche.redhat.com> References: <871u1j2ldi.fsf@fleche.redhat.com> Date: Mon, 16 Dec 2013 07:48:00 -0000 Message-ID: Subject: Re: [RFC/Patch] Call overloaded operators to perform valid Python operations on struct/class values. From: Doug Evans To: Tom Tromey Cc: Siva Chandra , gdb-patches Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes X-SW-Source: 2013-12/txt/msg00565.txt.bz2 On Wed, Dec 11, 2013 at 12:17 PM, Tom Tromey wrote: >>>>>> "Doug" == Doug Evans writes: > > Doug> I'm not yet comfortable enough with going this route to approve it. > > It seems fine to me. > > Doug> It feels sexy and all, but it's not clear to me going this path is > Doug> a net win. > > What are the negatives? Your email leaves little to either agree or > argue with. A little more insight into your reasoning might be useful. My concern is basically that one can only go so far mapping Python to the target language (or, can we get a "mode" (for lack of a better word) in Python of accepting the syntax of the target language?) Does it make sense to support what one can (arithmetic ops, a few others), and leave it at that? I don't know. Every feature adds complexity, and this feature can never be complete (I could certainly be wrong ... it would be interesting if all C++ operators could be supported). Note that I'm not disapproving the feature ... if someone else approves the patch I'm not going to object. For myself, I'm just going slow on this one. E.g., is there another way to provide this? E.g., some kind of facility that uses gdb's language parsers but let's one pass in gdb.Value objects from Python? It sounds doable, but I haven't thought about it very hard (it might not even make sense, or it may require more effort). Its drawback to the current proposal is that it would be a bit more verbose, but it has to potential of handling a lot more cases.