From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23687 invoked by alias); 11 Sep 2003 18:55:16 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 23653 invoked from network); 11 Sep 2003 18:55:14 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 11 Sep 2003 18:55:14 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8FA712B89; Thu, 11 Sep 2003 14:55:11 -0400 (EDT) Message-ID: <3F60C50F.5040704@redhat.com> Date: Thu, 11 Sep 2003 18:55:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hilfinger Cc: gdb-patches@sources.redhat.com Subject: Re: RFA: Changes to allow extensions to operator set References: <20030901093941.0D2E9F2A64@nile.gnat.com> <3F58B874.7020904@redhat.com> <20030906111343.5F98DF2B63@nile.gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-09/txt/msg00229.txt.bz2 >> [Where] is a method to handle operator evaluation missing? Otherwize won't >> the jumbo switch in evaluate_subexp_standard still need to be modified >> as languages add additional operators. > > > Not so. The language vector already contains > > /* Evaluate an expression. */ > struct value *(*evaluate_exp) (struct type *, struct expression *, > int *, enum noside); Ah. Is ada doing anything special with that - something that will bite later? Looking at the existing languages - they appear to simply be overriding select operators but nothing more. > In short, you want to object orient these suckers. Well as a matter > of fact, I actually implemented something along these lines in an earlier > iteration. It certainly can be made to work. However, Yes. > 1. To do it consistently requires a much more extensive and somewhat > tedious change to the existing machinery (which works well enough) > giving me even more opportunities to overlook something ("overlook" > == "screw up"). True. Need to look for baby steps. > 2. For example, to really do it up brown you'd want to modify all the > .y files so that instead of emitting the integer codes directly, as they > do now, there'd be operator-specific emission routines for parsing, so > that, e.g., sequences like > > write_exp_elt_opcode (OP_FUNCALL); > write_exp_elt_longcst ((LONGEST) end_arglist ()); > write_exp_elt_opcode (OP_FUNCALL); } > > became > > OP_FUNCALL->write_exp_longest ((LONGEST) end_arglist ()); > > or some such thing. Yes, eventually. In an as yet un-scheduled future round. > 3. Personally, I find that this is one of those gray cases where the OOP > style gains little in clarity. That is, we have choice of writing (A) an > enumeration type and a few big functions of the form > > () { > > switch () { > case A: > > case B: > > } > } This, I think, is easier short term. > and of writing (B) LOTS of little functions of the form > > () { > > > } This, I think, is easier long term - it's clear exactly which methods need to be implemented to make the new object functional - no chasing after all those switch statements to figure out if/where each needs to be changed. It took me some time to understand why the OO style really was better and how come Java omiting enum's was a good thing. > plus a big dispatch vector (of struct operators, in your case) naming them. > Perhaps I am overinterpreting your suggestion, but I see a lot of effort > for little gain in clarity (maybe <0) in going from the current style (A) > to style (B). In fact, for these reasons, I went so far as to tear up my > original, more bject-oriented version of this extension mechanism and > go back to the mechanism I submitted, as a simpler and more conservative > solution. sed would quickly create the initial table. > Now if and when David Carlton gets his way and we eventually re-do GDB > in C++, it might be time to revisit this decision, since C++ would > remove the tedious table building and welter of names. Not if, when. GDB's beeing re-done OO regardless of the C++ schedule. Can you please move evaluate_exp to the new expresion descriptor (is anything else missing?); modify: > + OP_OBJC_NSSTRING, > + > + /* First extension operator. Individual language modules define > + extra operators they need as constants with values > + OP_LANGUAGE_SPECIFIC0 + k, for k >= 0, using a separate > + enumerated type definition: > + enum foo_extension_operator { > + BINOP_MOGRIFY = OP_EXTENDED0, > + BINOP_FROB, > + ... > + }; */ > + OP_EXTENDED0, > + > + /* Last possible extension operator. Defined simply to specify a > + minimum range for the representation. */ > + OP_EXTENDED_LAST = 0xff to provide a an explicit and finite number of extended operators OP_EXTENDED_0, OP_EXTENDED_1, ... (I'm assuming Ada will contain enum { OP_ADA_... = OP_EXTENDED_0, ... }); add a note that this is an interum and it will go away. Andrew