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 20:00:50 +0300 Message-ID: <83618m230d.fsf@gnu.org> References: <87lhhjuq26.fsf@gmail.com> <87fv7r3rbh.fsf@gmail.com> <83iocn0x3x.fsf@gnu.org> <87sibr2b10.fsf@gmail.com> <83d22u278u.fsf@gnu.org> <87r3ra4xgu.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1429808468 15774 80.91.229.3 (23 Apr 2015 17:01:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 17:01:08 +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 19:00:59 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 1YlKUj-0003GD-B1 for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 19:00:57 +0200 Original-Received: from localhost ([::1]:41262 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKUi-0006Me-PM for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 13:00:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40373) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKUf-0006MS-L2 for emacs-devel@gnu.org; Thu, 23 Apr 2015 13:00:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlKUc-0000qM-FK for emacs-devel@gnu.org; Thu, 23 Apr 2015 13:00:53 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:53045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKUc-0000q8-7O for emacs-devel@gnu.org; Thu, 23 Apr 2015 13:00:50 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NN900800R77XO00@a-mtaout21.012.net.il> for emacs-devel@gnu.org; Thu, 23 Apr 2015 20:00:48 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NN90080FR9CUU70@a-mtaout21.012.net.il>; Thu, 23 Apr 2015 20:00:48 +0300 (IDT) In-reply-to: <87r3ra4xgu.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.169 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:185822 Archived-At: > From: Oleh Krehel > Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > Date: Thu, 23 Apr 2015 18:32:17 +0200 > > Why is it preferred to type BVAR (foo, name) instead of foo->name? Because it will then be easy to change the definition of BVAR into something less trivial. E.g., imagine this alternative: #define BVAR(buf, field) ((buf)->thread_storage (current_thread)->(field)) Or whatever, I hope you get the point. > This confuses me, because I can't use Semantic to assist me in what I'm > doing. For instance, starting with: > > kb->Vw > > Semantic can tell me that the only possible completions are Vwindow_list > and Vwindow_system. This is great for someone who's new, because I see > what options are available to me. This is also great for someone who's > experienced, because it still acts as a spell checker and speeds up > coding. I can't get the same benefits for: > > kb->INTERNAL_FIELD (Vwindow_system) = val; > > The first variant of the code feels like I'm in control of the code, and > I'm actually dealing with code. Using accessors has its downsides, yes. It makes the object more opaque. Perhaps Semantic should become smarter about this. But you aren't saying that accessors should not be used, are you? > >> 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? > > The kind of C++ libraries that I'm dealing with overload arithmetic > operators on vectors and matrices, actually simplifying the code. You have been lucky. In general, when you work with C++ libraries to which you have no sources, you can never know what the overloaded operators do, or how expensive they are.