From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Jonas Bernoulli Newsgroups: gmane.emacs.devel Subject: Re: Un-deprecating oset Date: Mon, 25 May 2020 19:27:23 +0200 Message-ID: <874ks4rklg.fsf@bernoul.li> References: <87eery1xhe.fsf@bernoul.li> <87a72d42h2.fsf@bernoul.li> <87a726tg3c.fsf@bernoul.li> <877dx1rt78.fsf@bernoul.li> <83zh9wujkx.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="95022"; mail-complaints-to="usenet@ciao.gmane.io" Cc: johnw@gnu.org, emacs-devel@gnu.org To: Stefan Monnier , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon May 25 19:29:59 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 1jdGvG-000ObA-NS for ged-emacs-devel@m.gmane-mx.org; Mon, 25 May 2020 19:29:58 +0200 Original-Received: from localhost ([::1]:41694 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jdGvF-0001aW-LT for ged-emacs-devel@m.gmane-mx.org; Mon, 25 May 2020 13:29:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40152) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdGsq-0008TW-Hj for emacs-devel@gnu.org; Mon, 25 May 2020 13:27:28 -0400 Original-Received: from mail.hostpark.net ([212.243.197.30]:44648) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jdGsp-0000xi-Hf; Mon, 25 May 2020 13:27:28 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by mail.hostpark.net (Postfix) with ESMTP id DDCFF1667E; Mon, 25 May 2020 19:27:23 +0200 (CEST) X-Virus-Scanned: by Hostpark/NetZone Mailprotection at hostpark.net Original-Received: from mail.hostpark.net ([127.0.0.1]) by localhost (mail0.hostpark.net [127.0.0.1]) (amavisd-new, port 10124) with ESMTP id coqzsF-16OIO; Mon, 25 May 2020 19:27:23 +0200 (CEST) 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 (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hostpark.net (Postfix) with ESMTPSA id 297C31666F; Mon, 25 May 2020 19:27:23 +0200 (CEST) In-Reply-To: Received-SPF: none client-ip=212.243.197.30; envelope-from=jonas@bernoul.li; helo=mail.hostpark.net X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/25 13:27:24 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -25 X-Spam_score: -2.6 X-Spam_bar: -- X-Spam_report: (-2.6 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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:251377 Archived-At: > I thought the whole CL -> CL-lib change was because we didn't want to > have in Emacs core libraries that stomp on the namespace FWIW I originally didn't like that move either but am now totally behind it. And while I haven't been consistently prefixing all symbols in all of my own packages, I am coming around here too. (I did whine a little when you raised concerns about the prefix-less symbols in Transient, but have fixed that now and think it is for the better.) Just mentioning these things (again) so you don't feel like you are up against someone who opposes the use of package prefixes on principle. Like Eli I support the whole prefixing endeavor, but feel like there should be exceptions and apparently I feel pretty strongly that this ought to be one of those. ;D > It seems rather odd that `defclass` is allowed into the core namespace > while `defstruct` had to be relegated to `cl-defstruct`. I was wondering about that too, it always seemed like an oversight to me. It makes even less sense if you consider `cl-defgeneric' and `cl-defmethod'. Jonas