Proposal-temporal: Do we need set functions for date parts?

[maggiepint]

What are the use cases for setting date parts? Are these really something that can't be achieved through add/subtract?

[domenic]

I'm confused, I thought all the objects were immutable?

[maggiepint]

Yep. It would be to return a new object with the same value as the old one
besides the set.

People use the setters all the time in Moment, but I'm wondering if the
reasons are bad.

On Jul 8, 2017 7:43 AM, "Domenic Denicola" [e-mail] wrote:

I'm confused, I thought all the objects were immutable?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/maggiepint/proposal-temporal/issues/30#issuecomment-313859704,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFxi0qN2JKoFfAKHusW0sgArgiq7TiOVks5sL5V1gaJpZM4ORpJF
.

[domenic]

I guess you mean functions, not setters?

[maggiepint]

Yeah. Clarifying in title.

[mj1856]

To be clear, we're wondering if people even care to do something like:

let d1 = temporal.createDate(2016, 1, 1);
let d2 = d1.withDay(31);
let d3 = d2.withMonth(2);
let d4 = d3.withYear(2017);

console.log(d1); // '2016-01-01'
console.log(d2); // '2016-01-31'
console.log(d3); // '2016-02-29'
console.log(d4); // '2017-02-28'

Or would one just construct new dates for each of these?

[icambron]

There needs to be some way to create a new date by changing only certain parts of an existing date. I've used this feature a million times in Moment. No one wants to take apart the existing date and plug most of those parts back into a factory function.

temporal.createDate(t.year, 3, t.month); //yuck

One alternative to individual "setters" is a copy constructor that takes specific overrides, like...

t.clone({month: 3}) //=> 2016-03-01

"Clone" is actually a terrible name in an immutable API, so maybe it's called something else like with or whatever, but you get the idea. This has two advantages over setters:

1. It doesn't require the user to do multiple changes in the right order. We know from Moment that if you do your sets in big endian order you end up with all sorts of nonsense, whereas setting everything in bulk allows the implementation to sort out the right order.
2. Fewer functions.

[doodadjs]

May I suggest "set" ? That's the name I found for all my immutable objects.

const newT = t.set({month: 3});

EDIT: Show the returned value.

[icambron]

Yeah, for FWIW, I used set in Luxon (here) and I like it, but I chickened out writing that comment.

[domenic]

+1 for with() instead of set(). In JavaScript we should not cause confusion by using method names normally associated with mutation for non-mutating purposes. In languages with pervasive immutability, it's OK, but in JavaScript, it'd be supremely surprising if set() did not actually mutate its this value.

[doodadjs]

I don't see any confusion problem with 'set' but anyway.... I find 'with' more confusing, in the sense of 'with' what ? May I suggest 'mutate' then ?

[domenic]

Maybe we are talking past each other. The idea is that these objects are always immutable. You cannot mutate them. Instead you create new objects derived from the existing ones but with certain components changed.

So a method named set() or mutate() would just be wrong, since it's impossible for it do what it's name says.

[doodadjs]

'with' has really no meaning, 'set' has. Maybe 'cloneWith' ?

[domenic]

Sure. That's just a more verbose version of with().

[pithu]

I would say there are some use cases for setters, eg.

// getting the birthday of somebody this year
somebodiesDayOfBirth.withYear(2017).isBefore(today)

// getting the day of week of the first day of the month
today.withDay(1).getDayOfWeek()

[maggiepint]

With made it into the spec, closing.