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 19:09:24 +0200 Message-ID: <87fv7q4vqz.fsf@gmail.com> 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> <83618m230d.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1429809339 30619 80.91.229.3 (23 Apr 2015 17:15:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 23 Apr 2015 17:15:39 +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 19:15:38 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 1YlKiw-0005Av-1g for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 19:15:38 +0200 Original-Received: from localhost ([::1]:41327 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKiu-0006HL-Pf for ged-emacs-devel@m.gmane.org; Thu, 23 Apr 2015 13:15:37 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44542) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKiY-0006Gz-57 for emacs-devel@gnu.org; Thu, 23 Apr 2015 13:15:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YlKiS-0006La-EW for emacs-devel@gnu.org; Thu, 23 Apr 2015 13:15:14 -0400 Original-Received: from mail-wg0-x22e.google.com ([2a00:1450:400c:c00::22e]:36189) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YlKiS-0006L1-8d; Thu, 23 Apr 2015 13:15:08 -0400 Original-Received: by wgen6 with SMTP id n6so25431665wge.3; Thu, 23 Apr 2015 10:15:07 -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=lyPrW0pMrNNBE7AvssGQD2JaGIEpLolo0hjXhFdvaMo=; b=CbqPUPqdCeyvP/kzw6oV9USBo8sZkqpGxuDUPPvqgJ05PsSp2O73sk2mg2zMNZlXie rkYSfEJFpCxutFeqgGvAx+CgAgFr0jyg2ZrAE3gL2pZWJW8ZRrSi80yaRDAlqrGixuzc Diz17y8a/Z746XZpNrWa65aVvzp4nInXGfscgTc8B1Si5G0uA7gtkB4ytgrffrqIqldn DCHOXDo8s8cRXYFkGxTIsCgtFQekc+Az4vtjuaOLIzvC9k5wksaOYxb/g4IjUUxcUy7c v3CWIc/ybluWyHc5SbyfjDT2S89TlzM4wEuWx6NBPAWu7svuGERRb0UMA4J5/mk994Qa 5IsQ== X-Received: by 10.194.173.226 with SMTP id bn2mr7456910wjc.148.1429809307580; Thu, 23 Apr 2015 10:15:07 -0700 (PDT) Original-Received: from firefly (dyn069045.nbw.tue.nl. [131.155.69.45]) by mx.google.com with ESMTPSA id qt2sm13029841wjc.7.2015.04.23.10.15.06 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 23 Apr 2015 10:15:06 -0700 (PDT) In-Reply-To: <83618m230d.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 23 Apr 2015 20:00:50 +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::22e 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:185825 Archived-At: Eli Zaretskii writes: >> 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. OK, fine. At least it's possible to cook up a viable heuristic for completing BVAR with Semantic, because it has the semantics of accessing the buffer object. INTERNAL_FIELD is just mental arithmetic, it doesn't do anything. It's possible to make a heuristic for it as well, but I like to see it removed instead. >> 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? I like accessors for C++, but I'm not really familiar with large scale C programming. Are macros really the state-of-the-art for making accessors? Oleh