Proposal-temporal: [Question/Feedback] why `minus` & `plus` ?

[romulocintra]

Hi,

I've been playing around with the Temporal polyfill, great work BTW 😉.

To manipulate dates & times it in some way, when using some of popular libraries you have the following:

import { add } from 'date-fns';
add(new Date(2014, 8, 1, 10, 19, 50), { days: 7 });

moment().add(7, 'days');

dayjs().add(7, 'day');

Temporal.now.absolute().plus({ days: 7 });

Or

import { sub } from 'date-fns';
sub(new Date(2014, 8, 1, 10, 19, 50), { days: 7 });

moment().subtract(7, 'days');

dayjs().subtract(7, 'day');

Temporal.now.absolute().minus({ days: 7 });

My question is why minus & plus instead of add & subtract ?

I understand the surface of the Temporal is completely different from libraries like moment, dayJS or date-fns but the target is the same the community or developer.

I think that would be nice to keep some relation between Temporal API's and actual use cases if they solve a similar or the same problem, this will improve adoption, migrations etc...

Probably I'm late to the party... but don't forget that moment(12.443.725) ,date-fns(6.499.163) & dayJS(1.941.696) together they have around 20 Million weekly downloads, I know that is not a competition but is worth to have a look at, time to time.

[ryzokuken]

Honestly? I don't know. Maybe it wasn't even a conscious decision, just something someone proposed and nobody opposed it. Thanks for the feedback and thanks for trying the polyfill out! We should take this into account and consider renaming these methods.

[ljharb]

I can't speak for the specific reasoning, but subtract is a bit longer to type, and potentially easier to misspell.

[InExtremaRes]

IMHO plus and minus are better in this case. add and substract sound too imperative for my taste, and since the instances are immutable with those operations returning new ones, the former are clearer and better express that fact; besides they sound better for me from and arithmetic POV. I know date-fns is also immutable so I'm not saying an immutable library _should_ follow those conventions, just expressing that _for me_ is a lot clearer if, for instance, foo.normalize() performs a normalization in foo (whatever that is) mutating that instance, but foo.normalized() returns a new "normalized" value leaving foo intact. Having said this, as always, consistency is better than "language purity" or even "math purity" (just for using a way to describe it).

[littledan]

How about added and subtracted? (Joking! Bikeshed threads should be fun!)

[justingrant]

embigificate and teensyweensyify would be my favorites. ;-)

[ptomato]

smoosh (and unsmoosh for subtraction). don't @ me

[littledan]

FWIW I asked @maggiepint, and she and @mj1856 don't remember why the names were chosen. They feel familiar, but no strong opinions one way or the other. (I feel similarly, personally.)

[kaizhu256]

adding to bikeshed,
my conspiracy-theory is plus/minus have operator-overloading connotations, and this was [perhaps unconscious] bias to promote operator-overloading.

+1 to add/subtract for consistency.

[gilmoreorless]

I can't speak for the specific reasoning, but subtract is a bit longer to type, and potentially easier to misspell.

I think that's a valid point. I've seen many, many instances of "subtract" being mistyped as "substract" in other code. In fact, according to the emails I got for this repo, the "substract" typo appeared 4 times in this thread alone (with some being corrected later). 😉

[ryzokuken]

While it is a valid concern, it would clearly not be on the more verbose end of the spectrum with respect to the current API. Besides, modern tooling (like autocompletion plugins and language servers) aim to make the situation much better. Because of this, I'd say that in my opinion, the consistency argument trumps the concern.

[justingrant]

Minor thing: I find it slightly easier when code makes sense as grammatical English e.g. "a plus b". Especially when you're describing code to someone verbally.

But I don't have a strong opinion either way. Either pair of names seen fine.

[ptomato]

I don't have a strong opinion here either. add/subtract is more consistent with other popular libraries, plus/minus read like a sentence and are not as hard to type as subtract.

[sffc]

I have a slight preference for add/subtract.

[ptomato]

In the Sept 4 meeting we decided to rename these to add and subtract.

[ljharb]

@ptomato i disagree with that decision. The OP misspelled it in the very creation of this issue - it will be more prone to error than plus/minus.

[romulocintra]

@ptomato i disagree with that decision. The OP misspelled it in the very creation of this issue - it will be more prone to error than plus/minus.

@ljharb In my case I will continue writing substract , subtact or any other combination instead of subtract, same happens to me when I misspell contract, conctrat or how vs who, sintax vs syntax, is something that I have to live with it but does not represent the totality of people that correctly uses those libraries.

[ljharb]

@romulocintra an individual's misspellings aren't the point, it's that it reflects how likely people are to get it right on the first try.

[littledan]

@ljharb I think this is drawing a very broad conclusion from not much data. A better place to look than the way this issue was written would be, do we see misspelling bugs about this name in the use of existing date-time libraries?

[ljharb]

That’s a fair point.

What were the reasons the decision was made in the 9/4 meeting?

[ptomato]

We considered the advantage of familiarity with libraries in common use, to outweigh the mistyping disadvantage.