From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: ams@gnu.org (Alfred M. Szmidt) Newsgroups: gmane.emacs.devel Subject: Re: dash.el [was: Re: Imports / inclusion of s.el into Emacs] Date: Wed, 13 May 2020 07:48:22 -0400 Message-ID: References: <35DBF02E-44D7-41E5-A217-7D6EC84ED221@icloud.com> <83d07984ux.fsf@gnu.org> <87d078b1hg.fsf@russet.org.uk> Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="27643"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, joostkremers@fastmail.fm, Emacs-devel@gnu.org, monnier@iro.umontreal.ca, pcr910303@icloud.com, eliz@gnu.org To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 13 13:48:56 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 1jYpsd-00073n-MG for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 13:48:55 +0200 Original-Received: from localhost ([::1]:46636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYpsc-00071t-P2 for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 07:48:54 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60362) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYps8-0006Yo-SK for Emacs-devel@gnu.org; Wed, 13 May 2020 07:48:24 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:34535) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYps7-00040N-UM; Wed, 13 May 2020 07:48:23 -0400 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jYps6-0005Of-6F; Wed, 13 May 2020 07:48:22 -0400 In-reply-to: <87d078b1hg.fsf@russet.org.uk> (message from Phillip Lord on Wed, 13 May 2020 10:58:19 +0100) 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:250116 Archived-At: 1) Incongruent functions: A situation we already have with deprecated functions, function aliases, and things like seq which overlaps with other emacs functions (albeit somewhat differently). Deprecated functions are marked as such, function aliases as well. Some functions, specifically in s.el, could have been aliases but are instead fresh implementations. It is definitly not the same situation. And don't you think that if there are badly named, or overlapping functions (in the context of overall Emacs, in isolation they might be well named), then instead of continuting adding more of the same situation, that one should instead try and fix it? 2) The s- namespace: This has already happened. If we put a function called `s-starts-with' or `-map' into core, we will break quite a lot of MELPA. This would look poor and potentially like bad will. Emacs cannot control what happens outside of Emacs -- if the library was called string-x.el and was super popular, and the prefix was string- the situation would have been exactly the same. Adding a function would break code, Emacs cannot control that. 3) "who don't coordinate with us". Magnar will respond if emailed. Is reading this mailing list really a criteria that makes sense. That is asking Emacs for coordinating with someone else. And you have missed the advantages: having libraries like s and dash available, will bring to Emacs a set of functionality that many people like, as well as bringing in a lot of developers who have already contributed to s.el, dash and the rest. And nobody is against adding functionality -- the issue is adding many overlapping, slightly similar, differently named functions. It is not the functionality that is the topic here.