From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Is it time to remove INTERNAL_FIELD? Date: Thu, 23 Apr 2015 18:29:21 +0300 Message-ID: <83d22u278u.fsf@gnu.org> References: <87lhhjuq26.fsf@gmail.com> <87fv7r3rbh.fsf@gmail.com> <83iocn0x3x.fsf@gnu.org> <87sibr2b10.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429802994 17353 80.91.229.3 (23 Apr 2015 15:29:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 15:29:54 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Oleh Krehel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 23 17:29:49 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YlJ4R-0002lU-GL for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 17:29:43 +0200 Original-Received: from localhost ([::1]:40852 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlJ4Q-0000dd-Jk for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 11:29:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45306) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlJ4J-0000d1-Uw for emacs-devel@gnu.org; Thu, 23 Apr 2015 11:29:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlJ4D-0001b0-RJ for emacs-devel@gnu.org; Thu, 23 Apr 2015 11:29:35 -0400 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:50683) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlJ4D-0001as-IE for emacs-devel@gnu.org; Thu, 23 Apr 2015 11:29:29 -0400 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0NN900G00MLGYP00@a-mtaout20.012.net.il> for emacs-devel@gnu.org; Thu, 23 Apr 2015 18:29:19 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN900G7EN0VUO80@a-mtaout20.012.net.il>; Thu, 23 Apr 2015 18:29:19 +0300 (IDT) In-reply-to: <87sibr2b10.fsf@gmail.com> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.166 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:185818 Archived-At: > From: Oleh Krehel > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Date: Thu, 23 Apr 2015 16:07:39 +0200 > > > What this macro does is allow you to use field names like 'foo', when > > the field is really called 'foo_'. > > > > I think it's okay to remove INTERNAL_FIELD, but I think we should keep > > the trailing underscore appended in BVAR and KVAR. > [...] > I'm totally fine with this: > > INLINE void > kset_last_kbd_macro (struct kboard *kb, Lisp_Object val) > { > kb->Vlast_kbd_macro_ = val; > } > > just as I'm fine with this: > > INLINE void > kset_last_kbd_macro (struct kboard *kb, Lisp_Object val) > { > kb->Vlast_kbd_macro = val; > } We are talking past each other. I wasn't talking about kset_last_kbd_macro etc, I was talking about expressions that explicitly mention field names. Like this one: foo->name = bar; or this: BVAR (foo, name) = bar; or this: buffer_name = BVAR (foo, name); It's the "name" part that I care about. If "BVAR (foo, name)" expands into "foo->name_", then no code can use bar->name anywhere without triggering a compilation error. But I, as code write, can still call the field "name" and use it in my code, and have the preprocessor append the underscore for me. > It's not obvious how simple or intricate INTERNAL_FIELD is or what it > does. At the first glance, looks like C++ member function call. And what's wrong with that? For someone who programs in C++, and should therefore be ready to accept overloaded operators that can compute the end of the world as part of their processing, how do you know, in C++, that "->" is not overloaded to do just that?