From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2628 invoked by alias); 6 Jun 2012 20:02:51 -0000 Received: (qmail 2618 invoked by uid 22791); 6 Jun 2012 20:02:51 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 06 Jun 2012 20:02:30 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q56K2TRl012645 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 6 Jun 2012 16:02:29 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q56JREGi030283 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 6 Jun 2012 15:27:14 -0400 From: Tom Tromey To: Sergio Durigan Junior Cc: GDB Patches Subject: Re: [PATCH 06/10] Java language References: <1338665528-5932-1-git-send-email-sergiodj@redhat.com> <1338665528-5932-7-git-send-email-sergiodj@redhat.com> <87pq9en7pd.fsf@fleche.redhat.com> Date: Wed, 06 Jun 2012 20:02:00 -0000 In-Reply-To: (Sergio Durigan Junior's message of "Mon, 04 Jun 2012 21:35:40 -0300") Message-ID: <87hauogs1a.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.97 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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: 2012-06/txt/msg00199.txt.bz2 >>>>> "Sergio" == Sergio Durigan Junior writes: Tom> IMNSHO language parsers should not be manipulating the expout data Tom> structure like this. copy_exp is likewise naughty. Sergio> Hm, do you have some idea here? Some kind of abstraction, like putting Sergio> these functions on gdb/{parser-defs.h,parse.c}, or something better? I think that accessors and mutators for a data structure should all live in one place. Spreading them out makes it harder to find them all when doing refactorings. (In many cases you can rely on the compiler to catch problems -- but you can still have planning difficulties due to not seeing the code). In the longer term, I think struct expression is just a crazy, old-school data structure that should be replaced with something more straightforward, even at the expense of using more memory. I think the reason it has stayed this way so long is that the cost/benefit for changing it is pretty low. This could be said of many of the goofier areas of gdb. Tom