From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eric Abrahamsen Newsgroups: gmane.emacs.help Subject: Re: plist-put: destructive? Date: Sat, 21 Jan 2017 16:50:53 -0800 Message-ID: <87tw8rx6he.fsf@ericabrahamsen.net> References: <87mvelzgrr.fsf@ericabrahamsen.net> <8737gcxt4e.fsf@ericabrahamsen.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1485046669 29186 195.159.176.226 (22 Jan 2017 00:57:49 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 22 Jan 2017 00:57:49 +0000 (UTC) User-Agent: Gnus/5.130014 (Ma Gnus v0.14) Emacs/26.0.50 (gnu/linux) To: help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Sun Jan 22 01:57:45 2017 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cV6TK-0005uk-O4 for geh-help-gnu-emacs@m.gmane.org; Sun, 22 Jan 2017 01:57:30 +0100 Original-Received: from localhost ([::1]:33907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cV6TP-0007Jt-Ok for geh-help-gnu-emacs@m.gmane.org; Sat, 21 Jan 2017 19:57:35 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:34556) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cV6NM-0006Yq-4w for help-gnu-emacs@gnu.org; Sat, 21 Jan 2017 19:51:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cV6NJ-00062p-1J for help-gnu-emacs@gnu.org; Sat, 21 Jan 2017 19:51:20 -0500 Original-Received: from [195.159.176.226] (port=56558 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cV6NI-00062j-Rd for help-gnu-emacs@gnu.org; Sat, 21 Jan 2017 19:51:16 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cV6Mz-0008CN-0w for help-gnu-emacs@gnu.org; Sun, 22 Jan 2017 01:50:57 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:N5HC6plNh3GiQMDrNZYXhCbDCbM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 X-Mailman-Approved-At: Sat, 21 Jan 2017 19:57:06 -0500 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.org gmane.emacs.help:112142 Archived-At: Drew Adams writes: >> Thanks to you both. I'm working with existing plists, so I'll drop >> the setqs, that's a relief. > > Why is it a relief - a relief from what? What if something reset your "existing plist" to nil behind your back? The code I'm working has many repeated clauses looking like: (when thing1 (setq the-plist (plist-put the-plist :thing thing1))) A little more complicated than that, but there will be like seven of those in a row. Probably I should just write myself a custom bulk-conditional-plist-setter macro, probably using the gv setter, but for the time being just being able to remove all the "(setq the-plist" makes everything easier to read. > Setting (again) a variable whose value is an object to which you've > applied a destructive operation is the standard idiom. And it is good > programming practice. It ensures that your code does what you expect, > regardless of the object value, or rather, regardless of the effect of > the operation. > > You naturally think of your variable as always pointing to the object that you expect. To keep this relationship, you must set the variable to the return value of any destructive operation. > > This is true for a possibly "destructive" operation on any kind of object. The poster-child case is a list. See, for example, (elisp) `Rearrangement' (http://www.gnu.org/software/emacs/manual/html_node/elisp/Rearrangement.html). > > The point is that your variable is otherwise not guaranteed to > continue to point to the object that you think it does. You need to > set it to the _result_ of the possibly destructive operation (the > return value), if you really want the variable to take the effect of > that operation into account. > > This is all about the difference between a variable and its object value. I understand the difference, but in this particular case I'm willing to drop the setqs. Eric