From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: [elpa] externals/transient 667ce2b287 18/23: Use transient-default-value in transient-init-value(suffix) Date: Fri, 27 Dec 2024 20:09:43 +0100 Message-ID: <87y101osco.fsf@bernoul.li> References: <173487507772.3820862.14263838078882905942@vcs3.savannah.gnu.org> <20241222134440.C5563C5C27C@vcs3.savannah.gnu.org> <87wmfmikc0.fsf@bernoul.li> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7411"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Dec 27 20:33:02 2024 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 1tRG4z-0001k5-Vr for ged-emacs-devel@m.gmane-mx.org; Fri, 27 Dec 2024 20:33:02 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tRG4B-000215-Nb; Fri, 27 Dec 2024 14:32:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRFif-000711-8L for emacs-devel@gnu.org; Fri, 27 Dec 2024 14:09:57 -0500 Original-Received: from mail.hostpark.net ([212.243.197.30]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tRFid-0002Hn-41 for emacs-devel@gnu.org; Fri, 27 Dec 2024 14:09:57 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id C0C9A16275; Fri, 27 Dec 2024 20:09:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=bernoul.li; h= content-transfer-encoding:content-type:content-type:mime-version :message-id:date:date:references:in-reply-to:subject:subject :from:from; s=sel2011a; t=1735326586; bh=QtFLkYLAU1p4Qta44ueFpU0 5KxMCaiwrEKVCaLZcy0o=; b=xp9AARxUKSXgwOOW7lZ2m8eKj3U9RzOhkKVcUuq WByY/WCirK/2kEI+0mnWmkxBMfNVL3VUFjxNKGILcFOprxB+ID3ZOsotC82tPINY gYvB5T3APA6Ohm/0owwY34xHYhhJLB+Jhl12nplNI/SMuQgchVmkZf6dWRyPcYp7 mNwo= X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail1.hostpark.net [127.0.0.1]) (amavisd-new, port 10224) with ESMTP id JPoXTp39s_wL; Fri, 27 Dec 2024 20:09:46 +0100 (CET) Original-Received: from customer (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 31EF8161E1; Fri, 27 Dec 2024 20:09:45 +0100 (CET) In-Reply-To: Received-SPF: pass client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Fri, 27 Dec 2024 14:32:10 -0500 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:327223 Archived-At: Stefan Monnier writes: >> The reason I am using Eieio's "this is not bound", is that I am doing an >> Eieio thing here. It's not a "not bound" slot but the "not bound" >> return value of a generic function, which isn't the same thing, but >> pretty damn close. > > =F0=9F=99=82 > >> Sure I can invent a new symbol just for this one case, but it would be >> (IMO unnecessary) noise and the only reasons I would be doing it is to >> make you happy and to avoid having a conversation about it. I think I'll leave it as-is. Since the effect of this function returning eieio--unbound is that the caller keeps using eieio--unbound as the "not-a-value" marker of this slot, I think that using this symbol is more appropriate than using any other symbol, which would obfuscate this relationship. > Sorry about this conversation. I'm not bothered by your use of > `eieio--unbound`, to be honest, I was just curious. > > [ If I were you, I think I'd just use something like `:unbound` or > `:transient--unbound` because it's literally less code than what you > currently have and it would save me from having to worry about the > annoying guy breaking compatibility again. ] Luckily I though about this remark long enough to realize that you were not calling me "the annoying guy". But wording that sentence like this was a bit risky... Anyway, sorry for the saltiness of my previous message. >>> IOW, is there a good reason to break the abstraction here? >> I am not sure what "the abstraction" and "here" refer to exactly. > > One of the abstractions is just that the `eieio--` prefix implies it's an > internal entity to EIEIO so shouldn't be used from outside of EIEIO's > own code. > > The other is that `eieio--unbound` is a value that ideally noone should > ever see, just like `Qunbound` in Emacs's C code. Every time you use it > you increase the risk that someone ends up storing it inside an > EIEIO object. My other package which uses eieio--unbound is closql, whose purpose is to store eieio object in a sqlite database. Since Eieio support unbound slots, I have no choice but to deal with them. And in this package I indeed have to be super careful when dealing with this symbol. Especially because it crosses the Lisp/SQLite border at which point the distinction whether eieio--unbound is interned or not is lost. (I.e., if someone actually stored an interned eieio--unbound in an object, then we lose.) > [ Now that I think about it... I'm no fan of EIEIO objects, especially > that notion of a slot being unbound, so maybe I should encourage use > of `eieio--unbound` so as to maximize the chance of mayhem. =F0=9F=99= =82 ] I expect that in 5 to 10 years you will present a new object system, until then I'll stick to this one. :P About the unbound thing, I have mixed feelings. But we all start at the beginning, i.e., when we know nothing about something and start learning about it. In the case of Eieio we learn (among many other things of course) that there is such a thing as unbound slots, and if we have no experience with other objects systems (which was the case for me), we cannot help but assume that there is a good reason for that feature to exist, and then move on to think about when to use it. Over time we learn about disadvantages of the feature and when not to use it. By now I initialize most of my slots with ":initform nil", but in a few cases it's still useful, and I figure if it exists, I might as well use it when that is the case. But I probably would not argue for the "unbound unless told otherwise" default, and if this did not exist at all, I probably would not miss it. But at this time removing this feature also does not sound feasible. Happy holidays! Jonas