Re: [ELPA] New package: transient

[Philippe Vaucher]

> > 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