From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Philippe Vaucher Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package: transient Date: Thu, 30 Apr 2020 20:14:28 +0200 Message-ID: References: <87ftcnxu5m.fsf@bernoul.li> <83y2qezlpd.fsf@gnu.org> <83tv12zjx1.fsf@gnu.org> <20200429172739.GB4002@ACM> <20200430115108.GA4287@ACM> <20200430123855.GA1444@tuxteam.de> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a8d2f505a4860a34" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="113916"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Mackenzie , Emacs developers To: tomas@tuxteam.de Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Apr 30 20:35:09 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 1jUE1c-000TW8-8r for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 20:35:08 +0200 Original-Received: from localhost ([::1]:55116 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUE1b-0007qQ-7f for ged-emacs-devel@m.gmane-mx.org; Thu, 30 Apr 2020 14:35:07 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36934) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jUDib-00019B-KI for emacs-devel@gnu.org; Thu, 30 Apr 2020 14:16:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jUDi5-0004bZ-Ct for emacs-devel@gnu.org; Thu, 30 Apr 2020 14:15:29 -0400 Original-Received: from mail-lf1-x12e.google.com ([2a00:1450:4864:20::12e]:45240) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jUDi4-0004bQ-TR for emacs-devel@gnu.org; Thu, 30 Apr 2020 14:14:56 -0400 Original-Received: by mail-lf1-x12e.google.com with SMTP id f8so2020912lfe.12 for ; Thu, 30 Apr 2020 11:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f7E3Fa6QdUP232Umhe6AY3r/EOBFoVHxRC4UxvRr/NE=; b=Pk3yUBUNvlhJo4s+a+F+lKjQyUg/lc/K9WaFoJSZSgUPONiaZ45l0cjOyfuS2ie8bg WrfLNxc3aWH7XVXOTJi+ImRGd0aT6TbypfrkltJwDaQBgZxPziiWknp/1bG4WhhMY+55 QpUgD3oY9k5UwJ2Zaf8e7X9oPOxbQ32UwmmeBAcqgHw+X+r6tTKzGh1nukMig/hhCgy9 g8zHabQLx9NLRCUUkHzxZVC/GFUR+PIjNWljVsMnlqCDYSqG6oRpSjfpPjgwEpj61fXQ bc1bmKXJvrvTcICxmyWLLAa365Hx5dwhCXjHmYHI8qgLD/Jk8hvOVTvhEPx079+2eukv svIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f7E3Fa6QdUP232Umhe6AY3r/EOBFoVHxRC4UxvRr/NE=; b=T1CUUpOZYrrxU2+Wu932kzicx76XMqVtF21rc/JuKNXHlvObFGNkLCqvn0rtRYeJCx ZZXvRjZunbb+vOC50vR6Yav52hPIxW26uF+0c9spQfNe4q+sM7r5jlqpseMTMmMHj8Qc +kzG8wA5ztYr4WYaV1SN6XYM/pCMAckIbr5iZrTMms1J10JPb4Uh8X0zVK0kVsORQ8Df PmhCnOyMjrGubHZnD11ldEVoA8Y/6IU4txZ7QGivugldMPTek7Ao3gg48KRzDJcJjg3D cT/PzLQy9RaF8rVczP1MVSKMIYADEWO6PcASCJr/eVAel59nIKoYkAySgp9CSyl4Vdh1 WQIQ== X-Gm-Message-State: AGi0Pua37+IQnSKaBlzo3Ycmq0B8tr9vbUmSvj+D1VzjOCtqg3L67Ja5 eXcp7Yc7EBBDy2XLvsCAAZol6c/hUZj9zqGIcKtjXAZ7t1s= X-Google-Smtp-Source: APiQypIIoXVwC7DBzTqEMOUcKLmsQ14gIoNlsKncmellBTZcoKlysgQAl3fkTErx7h4/buzPu7puoL8w9V3L5ntP8Es= X-Received: by 2002:ac2:4248:: with SMTP id m8mr3057647lfl.211.1588270494961; Thu, 30 Apr 2020 11:14:54 -0700 (PDT) In-Reply-To: <20200430123855.GA1444@tuxteam.de> Received-SPF: pass client-ip=2a00:1450:4864:20::12e; envelope-from=philippe.vaucher@gmail.com; helo=mail-lf1-x12e.google.com X-detected-operating-system: by eggs.gnu.org: Error: [-] PROGRAM ABORT : Malformed IPv6 address (bad octet value). Location : parse_addr6(), p0f-client.c:67 X-Received-From: 2a00:1450:4864:20::12e 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:248255 Archived-At: --000000000000a8d2f505a4860a34 Content-Type: text/plain; charset="UTF-8" > > > > Yes, and given we can make aliases to the old names we don't break > > > backward compatibility, and we can reasonably easily write something > > > that converts existing code to the new names, and eventually deprecate > > > the old names :-) > > > > That looks strongly to me about replacements. And note you used the verb > > form "can" rather than the more gentle, conditional form "could". > > That's it. Although my feeling is that your (Alan) reaction was too > sharp, I also feel that you, Philippe, disregard the cultural aspects > of your proposal -- your approach "hey, let's deprecate this-and-that" > is bound to ruffle some feathers and even hurt some people. > I'm amazed that you reach this conclusion based on this story. My main argument was "hey, let's add a clearer api where it makes sense, so things are better namespaced". People kept nitpicking about the alist example not being good enough, so I raise other examples where it's more obvious (file*, buffer*, process*, window*) but people keep on going back to the alist example, as if it's impossible for you to steelman my argument. Anyway Stefan agreed and proposed something about list. I said good idea and we can make alias to the old names (that means KEEP the old names), and EVENTUALLY (in a far future) deprecate the old names, and what you guys deduce from this? That I want to rename the existing API right now. This is strawmaning my position, I believe you wanted me to have this position because you felt threatened by change. > And when people react ("hell, no!"), you're offended and drive deeper > in your denial of the "other side's" points. > It looks like you never consider that I'm not denying the other side's point, I'm saying they are not relevant to my argument. IMHO valid rebuttals to my argument would have been: - It's too much work. - The supposed advantages are not demonstrated. - It will create two APIs to maintain (even tho they would only be aliases but still a valid argument). But certainly not: - look, some parts of the string library in C does not follow this so your idea is not valid - emacs lisp is not namespaced because that is how we filter smarter people - if we start namespaceing one api then we will end up with math.+ because it's impossible to apply your idea in a sane way Of course I also strawman your arguments here, but you'd get my point. Address the center of the target, not its periphery. Kind regards, Philippe --000000000000a8d2f505a4860a34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
> > Yes, and given we can make aliases to the old = names we don't break
> > backward compatibility, and we can reasonably easily write someth= ing
> > that converts existing code to the new names, and eventually depr= ecate
> > the old names :-)
>
> That looks strongly to me about replacements.=C2=A0 And note you used = the verb
> form "can" rather than the more gentle, conditional form &qu= ot;could".

That's it. Although my feeling is that your (Alan) reaction was too
sharp, I also feel that you, Philippe, disregard the cultural aspects
of your proposal -- your approach "hey, let's deprecate this-and-t= hat"
is bound to ruffle some feathers and even hurt some people.

I'm amazed that you reach this conclusion bas= ed on this story. My main argument was "hey, let's add a clearer a= pi where it makes sense, so things are better namespaced".

People kept nitpicking about the alist example not being good enough= , so I raise other examples where it's more obvious (file*, buffer*, pr= ocess*, window*) but people keep on going back to the alist=C2=A0example, a= s if it's impossible for you to steelman my argument.

Anyway Stefan agreed and proposed something about list. I said good= idea and we can make alias to the old names (that means KEEP the old names= ), and EVENTUALLY (in a far future) deprecate the old names, and what you g= uys deduce from this? That I want to rename the existing API right now.

This is strawmaning my position, I believe you wanted= me to have this position because you felt threatened by change.
=
=C2=A0
And when people react ("hell, no!"), you'r= e offended and drive deeper
in your denial of the "other side's" points.
=

It looks like you never consider that I'm= not denying the other side's point, I'm saying they are not releva= nt to my argument.

IMHO valid rebuttals to my argument wo= uld have been:

- It's too much work.
- The supposed advantages are not demonstrated.
- It will create= two APIs to maintain (even tho they would only be aliases but still a vali= d argument).

But certainly not:

- look, som= e parts of the string library in C does not follow this so your idea is not= valid
- emacs lisp is not namespaced because that is how w= e filter smarter people
- if we start namespaceing=C2=A0one api t= hen we will end up with math.+ because it's impossible to apply your id= ea in a sane way

Of course I also strawman your ar= guments here, but you'd get my point. Address the center of the target,= not its periphery.=C2=A0

Kind regards,
Philippe
--000000000000a8d2f505a4860a34--