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 16:07:39 +0200 Message-ID: <87sibr2b10.fsf@gmail.com> References: <87lhhjuq26.fsf@gmail.com> <87fv7r3rbh.fsf@gmail.com> <83iocn0x3x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429798422 30388 80.91.229.3 (23 Apr 2015 14:13:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 14:13:42 +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 16:13:42 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 1YlHsg-0006hz-NA for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 16:13:30 +0200 Original-Received: from localhost ([::1]:40479 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHsf-0001Li-TD for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 10:13:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52661) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHsb-0001Jy-CI for emacs-devel@gnu.org; Thu, 23 Apr 2015 10:13:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlHsX-0004dY-0O for emacs-devel@gnu.org; Thu, 23 Apr 2015 10:13:25 -0400 Original-Received: from mail-wg0-x233.google.com ([2a00:1450:400c:c00::233]:34962) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlHsW-0004dO-QU; Thu, 23 Apr 2015 10:13:20 -0400 Original-Received: by wgyo15 with SMTP id o15so19800825wgy.2; Thu, 23 Apr 2015 07:13:20 -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=fXl1WySfV91KhR9as7nZ6PfhGHoh4Br3+35jPuO7U9o=; b=HXjSEeqBq6olOSY7zqZwVTbX22pvCh6KwnfrtaewK2CozvDElusQV3vz3RwXMtSH+B dtJ49AW7hdXE8kyJTWYQV9gqUEFKYKsCEw0KpKv8cEf2preshnMhWzQgByY9kHNppZHE jFqV1+3U4HnWw8lnDalZesy0xuznHmo9Kc7I3t7y7aZyoZ392Yn2L6gujIy7wRV/Jtfy A1iqB9wvSWYOINp/6f2IzmBLkBNWOTK3tKqfZ45esOpZVIoKqayLEqgZWcd2OiuXN176 TEnFFrDuiOgaHngC3K9GepwSrJDAcmkixWVRIw7bH4Gpr64R8Z3Xkj/Zzxoa8OZyx5Fx vWig== X-Received: by 10.180.109.79 with SMTP id hq15mr6158316wib.93.1429798400234; Thu, 23 Apr 2015 07:13:20 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id u6sm12324987wjy.13.2015.04.23.07.13.19 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Apr 2015 07:13:19 -0700 (PDT) In-Reply-To: <83iocn0x3x.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 16:53:38 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c00::233 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:185815 Archived-At: Eli Zaretskii writes: >> From: Oleh Krehel >> Date: Thu, 23 Apr 2015 15:30:26 +0200 >> Cc: emacs-devel@gnu.org >> >> we should remove the macros that don't do anything. > > 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. That's how all > this started: the fields were renamed to have a trailing underscore so > that code that used foo->bar instead of BVAR (foo, bar) would be > immediately flagged by the compiler. > >> As for accidental access, I'm sure these rare errors will be caught by >> the code review / test suite. > > We don't want to rely on code reviews, since they are very informal > and their coverage is too low to be efficient. > > Based on bitter past experience with similar errors that lay low for > months, sometimes for years, I'd rather not give up those underscores > in BVAR and KVAR, which means the struct fields should retain them. 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; } Both are boilerplate that doesn't require additional thought. In the first case, it's maybe more explicit that `Vlast_kbd_macro_' should not be accessed outside the interface function `kset_last_kbd_macro'. But this I don't like: INLINE void kset_last_kbd_macro (struct kboard *kb, Lisp_Object val) { kb->INTERNAL_FIELD (Vlast_kbd_macro) = val; } 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. Oleh