From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14388 invoked by alias); 16 Aug 2002 19:51:36 -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 14381 invoked from network); 16 Aug 2002 19:51:35 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 16 Aug 2002 19:51:35 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7GJfUa11836; Fri, 16 Aug 2002 14:41:30 -0500 To: Petr Sorfa Cc: "gdb-patches@sources.redhat.com" Subject: Re: [RFA] Patch for supportinf DW_TAG_module / FORTRAN modules References: <3D34883C.4AAC7EE@caldera.com> <3D5D5221.D9854F8F@caldera.com> From: Jim Blandy Date: Fri, 16 Aug 2002 12:51:00 -0000 In-Reply-To: <3D5D5221.D9854F8F@caldera.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00449.txt.bz2 Petr Sorfa writes: > > It seems to me like it would work, since a class establishes a scope > > that behaves very much like a module. Isn't Class::member, where > > member is a static thingy, very much like Module::member (or whatever > > the Fortran syntax is)? We already have logic for resolving class > > scopes; I don't immediately see why module scopes need to behave any > > differently. > I thought it did this. Can you point out where I'm going wrong? Your patch is right, as far as I can see. In that paragraph I'm just saying why I think the patch should work fine. In the next paragraph I explain my reservations. > > But I think a module should be represented by something that calls > > itself a module, not a typedef. How will people feel reading a > > comment explaining that a LOC_TYPEDEF for a type with TYPE_CODE_CLASS > > is how we represent Fortran modules? I'm not sure that counts as good > > maintenance. > I originally introduced a TYPE_CODE_MODULE that was basically equivalent > to a TYPE_CODE_CLASS, as much as TYPE_CODE_CLASS is really > TYPE_CODE_STRUCT. I think I must have pulled it out for the patch. I can > put it back in and make it equivalent to TYPE_CODE_CLASS. If we're going to use a struct/class-like thingy to represent a Fortran module, then we should at least add DECLARED_TYPE_MODULE (see DECLARED_TYPE_CLASS, ... in gdbtypes.h). > > Or maybe this is okay for now. When we provide better support for C++ > > namespaces, Fortran modules can become a variant of that, which feels > > like a better fit. > Yes. *Cough* maybe this patch can provide support for namespaces? ;o) I'm not sure I really want the C++ `std' namespace represented as a struct type.