From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Oleh Krehel Newsgroups: gmane.emacs.devel Subject: Re: Is it time to remove INTERNAL_FIELD? Date: Thu, 23 Apr 2015 18:32:17 +0200 Message-ID: <87r3ra4xgu.fsf@gmail.com> References: <87lhhjuq26.fsf@gmail.com> <87fv7r3rbh.fsf@gmail.com> <83iocn0x3x.fsf@gnu.org> <87sibr2b10.fsf@gmail.com> <83d22u278u.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429807107 24639 80.91.229.3 (23 Apr 2015 16:38:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 16:38:27 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 23 18:38:27 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 1YlK8u-0002gY-QU for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 18:38:24 +0200 Original-Received: from localhost ([::1]:41194 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlK8u-0006Vn-9J for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 12:38:24 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32794) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlK8c-0006T5-7b for emacs-devel@gnu.org; Thu, 23 Apr 2015 12:38:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlK8X-0000ly-7B for emacs-devel@gnu.org; Thu, 23 Apr 2015 12:38:06 -0400 Original-Received: from mail-wg0-x232.google.com ([2a00:1450:400c:c00::232]:36155) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlK8W-0000lq-TU; Thu, 23 Apr 2015 12:38:01 -0400 Original-Received: by wgen6 with SMTP id n6so24369458wge.3; Thu, 23 Apr 2015 09:38:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=6/pZcB1UTIGJgUJEKO8dajwTmQZkIM1Nqv+w07LcDks=; b=UNwBvSyrku7ZDXGTBSJG4SiCCzc1AamsQn2WsATQK6eXpzeoeC3A+AMs4CQh+opVKY DM2eW5nanL46EDIk2U1zubE4GKKpyYdt+AvXspE4wTAv29uuDAjNj9mLCPUq23RkPWGU /PnKhBVv4uXo3JOFONhoOoT4snjr8oUtUe0WfxAumUlcRHOPkXOhNLoQPC5rbgNmMdzg i19kr2mEwVGyMO3ktPcdF3VogMtjziz67piM55LH2Rlpo4a+6ba4JeOe253eYmyI+63e tJov8c8TQkUN3IJn6fNk40WR+7EF0JaVvfnOKdnMqurslzlIjc3FgP4Ed70+jgAp4SSS iHNg== X-Received: by 10.180.87.105 with SMTP id w9mr16840871wiz.32.1429807080179; Thu, 23 Apr 2015 09:38:00 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id z12sm12885805wjq.12.2015.04.23.09.37.59 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Apr 2015 09:37:59 -0700 (PDT) In-Reply-To: <83d22u278u.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 18:29:21 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::232 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:185821 Archived-At: Eli Zaretskii writes: >> [...] >> 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. Why is it preferred to type BVAR (foo, name) instead of foo->name? 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. The second variant feels like I'm doing incantations, keeping fingers crossed that it works, and actually dealing with text and not with code. >> 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. INTERNAL_FIELD simply does string substitution. That's not immensely useful and it hampers completion and introspection. Oleh