From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Removing the usage of X structures (or their names) in independent code Date: Thu, 09 May 2019 20:12:03 +0300 Message-ID: <8336lnh7rw.fsf@gnu.org> References: <875zqkdzfc.fsf@gmail.com> <83d0ksgo1h.fsf@gnu.org> <87woizd263.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="29896"; mail-complaints-to="usenet@blaine.gmane.org" Cc: emacs-devel@gnu.org To: Alex Gramiak Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu May 09 19:18:10 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hOmgL-0007eb-Db for ged-emacs-devel@m.gmane.org; Thu, 09 May 2019 19:18:09 +0200 Original-Received: from localhost ([127.0.0.1]:58302 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOmgK-00070y-Al for ged-emacs-devel@m.gmane.org; Thu, 09 May 2019 13:18:08 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:53987) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOmaq-00021i-9c for emacs-devel@gnu.org; Thu, 09 May 2019 13:12:29 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hOmaq-0003YA-8Q; Thu, 09 May 2019 13:12:28 -0400 Original-Received: from [176.228.60.248] (port=2245 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hOmam-0002fA-RC; Thu, 09 May 2019 13:12:27 -0400 In-reply-to: <87woizd263.fsf@gmail.com> (message from Alex Gramiak on Thu, 09 May 2019 10:26:44 -0600) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:236341 Archived-At: > From: Alex Gramiak > Cc: emacs-devel@gnu.org > Date: Thu, 09 May 2019 10:26:44 -0600 > > > Why do you prefer a union? It uglifies the code and makes it harder > > to read and understand. OTOH, having a backend-independent type (what > > you call "typedef") is much cleaner. > > The union approach would be more future-proof (if the goal of multiple > backends at once is realized), and I find it neater than having > different types per backend. I would consider the union approach as > having a "backend-independent type"; in the union approach, all backends > of Emacs would have that union as the type, whereas in the typedef > approach each backend pastes its own type into the generic parts of the > code. > > The above goal is still far away, so it wouldn't be terrible to use > typedefs in the interim. Yes, I'd prefer not to make changes that are needed by future far-away goals, especially when those changes makes the code less readable. > > If that new structure is defined as (for example) > > > > typedef XColor EColor; > > > > then there's no overhead at all: you could simply assign an EColor to > > XColor or even use the former directly in APIs that want the latter. > > Right, I meant overhead in the case of defining a new structure rather > than defining a new name for the structure. For example: > > struct EColor > { > uint16_t red; > uint16_t blue; > uint16_t green; > uint16_t alpha; /* Who knows, maybe? */ > unsigned long long pixel; > }; > > Which would need to be converted to XColor on the X backend. But that's not needed if you use typedef as above for X. And for non-X platforms we already have a definition of XColor, which just needs to be renamed to EColor. > > For more complex situations, see what we do with 'struct font' and > > 'struct FOOfont' for font backend FOO. > > Could you point me to somewhere specific for this? I'm unsure to what > you're referring. For example, in ftfont.h: struct font_info { struct font font; #ifdef HAVE_LIBOTF bool maybe_otf; /* Flag to tell if this may be OTF or not. */ OTF *otf; #endif /* HAVE_LIBOTF */ FT_Size ft_size; int index; [...] } And an example how this is used in xftfont.c: static int xftfont_draw (struct glyph_string *s, int from, int to, int x, int y, bool with_background) { block_input (); struct frame *f = s->f; struct face *face = s->face; struct font_info *xftfont_info = (struct font_info *) s->font; This is for when you need to extend a platform-independent struct (in this case 'struct font') with platform-dependent additions. > In any case, would you prefer using names like EColor, EPixmap, EGC, or > Emacs_Color, Emacs_Pixmap, Emacs_GC? The Emacs_ prefix is short enough, so I guess it's better.