[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?
From: |
Jonas Bernoulli |
Subject: |
bug#73853: 31.0.50; Should and-let* become a synonym for when-let*? |
Date: |
Tue, 29 Oct 2024 16:21:57 +0100 |
Hello all,
It is very disappointing that you have chosen to deprecate if-let and
when-let in such a rushed manner. The same was done and reverted in
2018, and many of the same actors are involved this time around.
I am surprised that you would make the same unforced error again.
Reading through this and past conversations it is clear that there is no
consensus what the ultimate goal is. But as far as I can tell, few, if
any, are fully satisfied with the current (30.0.*) situation. There
also seems to be agreement that unfortunate mistakes were made in the
past, which limits our options now.
This could have been prevented if more people (including non-debbugs and
non-emacs-devel regulars) were given a chance to think about the problem
and time to articulate their concerns and proposals, before facts were
created. Or even if the people who did take part in past conversations
had spend more time actually talking things through.
The same could have been done every time the dissatisfying state of the
foo-let forms was brought up again, but instead new facts were rushed at
every turn.
Without stopping this destructive pattern, you won't be able to fix this
mess.
My short-term proposal is this:
- Revert the depredations and remove the news entry.
Even if you later decide to go through with the deprecation after
all, the "damage" done by doing, reverting and redoing a few lines is
minimal. (Even so, maybe discuss it for a few days before reverting.)
This would have the benefit of not needlessly alienating those package
authors who currently use foo-let and would like to keep doing so, if
the ultimate decision is to not go through with the deprecation after
all.
- Do NOT revert the changes from using foo-let to using foo-let* in
Emacs itself.
You might end up deciding to go through with the deprecation after
all, in which case it would be unfortunate to switch thousands of
lines back and forth.
- Re-read past conversations.
Think about what *your* ideal solutions would be (think big here).
Think about what your best *feasible* solutions would be. Think about
what compromises you would be willing to make. Think about what
compromises you would *not* willing to make, and articulate why.
Think about what others have said, and what compromises they would
have to make to satisfy your position and those of others. Try to
understand where they are coming from. You do not have to *agree*
with their motivations, to appreciate how severe the concessions are,
they would have to make to *them*, to agree to your idea of the
best feasible solution and your idea of an acceptable compromise.
Think in particular about whether achieving your goal/compromise,
would require them to roll over and admit defeat. Consider whether
sticking to the current (30.0.*) status quo, might after all be the
best *compromise* we could possibly reach.
- Do not have this conversation just among yourselves. Any change
you make here is going to affect *many* packages and their authors and
users. Actively involve the affected community. Reach out on several
channels, and give people time to think about the problem and share
their thoughts. I am talking months here, not weeks or even days.
- In addition to thinking about the state you want to reach eventually,
also think about the transition process. Should it be done in several
steps, and if so, what would the consequences for package authors be?
Could it be done in a way that does not force package authors to
change their code multiple times? Could a variable similar in spirit
to lexical-binding be a viable option?
- If you think that this proposal is over the top, try to consider it
from the perspective of the maintainers of external packages. Take
the history of this whole saga into account. Realize that there are
people who have been burned by this before and who will be upset if
being forced to change their packages again, maybe in a way they see
as a step backward. Even if you decide that those who disagree with
you are simply wrong and/or lack good taste, consider whether it is
worth alienating people over this.
To help kick start an informed decision finding process I have searched
the Emacsmirror (a superset of GNU ELPA + NonGNU ELPA + MELPA) for these
forms:
| grep pattern | hits |
|---------------------+------|
| "(if-let\( \|$\)" | 1853 |
| "(if-let\*" | 422 |
| "(when-let\( \|$\)" | 4260 |
| "(when-let\*" | 1162 |
| "(and-let\*" | 288 |
Best regards,
Jonas
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, (continued)
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Stefan Monnier, 2024/10/27
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Michael Heerdegen, 2024/10/28
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Stefan Monnier, 2024/10/28
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Drew Adams, 2024/10/27
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Howard Melman, 2024/10/27
- bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?, Sean Whitton, 2024/10/27
bug#73853: 31.0.50; Should and-let* become a synonym for when-let*?,
Jonas Bernoulli <=