From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Un-deprecating oset Date: Tue, 05 May 2020 10:50:39 -0400 Message-ID: References: <87eery1xhe.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="60141"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Jonas Bernoulli Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 16:51:27 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jVyut-000FWP-8F for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 16:51:27 +0200 Original-Received: from localhost ([::1]:56382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVyus-0005vn-8X for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 10:51:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37090) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVyuF-00053m-Qn for emacs-devel@gnu.org; Tue, 05 May 2020 10:50:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:49064) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVyuD-0000mT-Vj for emacs-devel@gnu.org; Tue, 05 May 2020 10:50:46 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 780BC80D7D; Tue, 5 May 2020 10:50:44 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3D09481360; Tue, 5 May 2020 10:50:42 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1588690242; bh=DL/l3u1TJhpPg6FMk4+pzTAUhacH4/OIC+jhHYKojLw=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=oxvESjos2b4h4GnJaM0Ki/1iID4SiLeRj9tJXwwXbgjjVynUSn9XdotiQoTj89pFt JniBaDYAaDR2TXWcbhEeJ/mda7Mqk8w83i9bfq4V64x3is7hwQ7IDafkRkMGs9L6iX 1NbvTpj5qJft+KpylYX816iNS0DKsQdsEP2K1y18SeNPC8WQy/s43HHudT3zaHKRig NgF//N8zEyoMc1WePiNUNpSdBstC5nO1ROqh5w+uPBpi06/E/jjRkjFt/Bw6++k1BP Rmp3TmKeONuW+M1fnenRLbfZncbsIEvT+CBFjxVzQY8XyGP2R1mrDd8v7aX31rJ/AW FmrcPUXcrHOAA== Original-Received: from alfajor (unknown [216.154.3.202]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E98A912023D; Tue, 5 May 2020 10:50:40 -0400 (EDT) In-Reply-To: <87eery1xhe.fsf@bernoul.li> (Jonas Bernoulli's message of "Tue, 05 May 2020 12:34:37 +0200") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/05 09:45:35 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:248996 Archived-At: > I used to assume that `oref' and `oset' were traditional CLOS functions > but now that I have actually looked around a bit I realize I likely was > wrong about that. Indeed, CLOS uses `slot-value` instead. > I found some documents about CLOS that mention `slot-value' and > `with-slots' In my mind (and I expect it's also the case in all implementations), `with-slots` is built on top of `slot-value`. > but never `oref' and `oset'; so now I assume that the latter two are > EIEIO additions. Indeed. > I can think of the following approaches to set a slot: > 1. (oset object slot value) > 2. (eieio-oset object 'slot value) > 3. (setf (oref object slot) value) > 4. (setf (eieio-oref object 'slot) value) > 5. (setf (slot-value object 'slot) value) > 6. (with-slots (slot) object (setq slot value)) Right. And only 5 and 6 work in CLOS. > Above you state the goal of "namespace sanity" and suggest the use of > [2]. That seems to make a lot more sense and one might argue that the > deprecation warning should be changed to make that suggestion. I don't have a strong preference either way: I'm more interested in deprecating `oset` than in the choice of the alternative we should recommend. But FWIW, I chose (3) as the recommendation on the following basis: - I expect most people to consider `eieio-oset` as an ugly name. - `setf` on `slot-value` is significantly more verbose and hence will encounter more resistance. - I like `setf` and using it sometimes makes further rewrite more obvious when the textually identical (oref X Y) appears. E.g. (oset X Y (cons Z (oref X Y))) vs (setf (oref X Y) (cons Z (oref X Y))) where I don't know about you, but my brain tends to suggest (push Z (oref X Y)) when it sees the second but not the first. But again I'm not at all wedded to this suggestion (and we can also recommend *several* options if we want). > You mention that you do NOT intend to remove `eieio-oset'. And that > can only mean that `eieio-oref' is safe too -- right? Yes. They're safe because they use the `eieio-` prefix which cleanly belongs to (and is used by) the `eieio` package. > But what about `slot-value'? Good question. There's something to be said for bringing it into the `cl-` namespace (along with `defclass`) but it hasn't happened yet and I haven't found the stamina to undertake this job. [ To be honest, I dislike EIEIO: not only it stomps all over the namespace but I dislike objects whose field access requires a hash-table lookup, which is why I only use `cl-defstruct`. ] > "get/set the value"-functions should all have rather short names and > that this does not only apply to the most important such functions, > like `setf', but also to e.g. `get'/`put' and, yes, `oref'/`oset'. Makes sense (tho I'm in the camp of those who prefer to strive for immutable objects, so I do want a concise object-access but I'm quite willing to use a significantly more verbose object-modification syntax). > Object-oriented programming is not a core language feature, but does > that mean it has to be treated as a second class citizen? That is definitely not the intention. > The deprecation of `oset' appears to be motivated by two IMO unrelated > goals: > > A. Take another step towards the elimination of prefix-less symbols. > > B. Avoid unnecessary setters. Use `setf' instead. The goal was only (A): we can't avoid setters because they are visible in the macroexpansion of `setf` and get stored in `.elc` files. So while I did choose the `(setf (oref ..) ...)` recommendation based on a preference for `setf` there is no intention to *avoid* setter functions, because setter functions are indispensable (even if they don't appear in the source code). Common Lisp does try to avoid setter functions and *can* hide them, but Elisp can't really hide them. > II. I might come to agree that `oref' and `oset' should get a > prefix. I would probably argue that it should not be `eieio-' > but maybe `cl-' or `slot-'. Or `object-get' and `object-set', > I suppose. I think the design of the namespacing of `oref` would have to be done along with that of `slot-value`, `defclass`, etc... > III. But I simply do not understand how it makes sense to deprecate > `oset' without *at the same time* deprecating `oref' as well. I could go along with that. I expect this will encounter more resistance, tho. > - Without assurances otherwise, I cannot shake off the feeling > that as soon as I have gotten used to `oset' not being around > anymore, then `oref' will be removed as well. (I would rather > get it over with in one go.) "As soon as": I'd say it's unlikely. > It does however take away the programmers choice whether to use > `setf' or not, but only when it comes to OOP, which seems unfair. I don't understand this "programmers choice" argument. You can use either `eieio-oset` or (lambda (..) (setf (oref ..) ..)) if you need a function, so the choice still exists just as much as before. Stefan