Consistent method prefixes about proposal-temporal HOT 9 CLOSED

The threeten get method prefix should be omitted, because its quite uncommon for javascript. More common is to simply get the value by name like date.year().

With the objects being immutable, it might be nice to make these read-only properties.

date.year === 2017 instead of date.year() === 2017

from proposal-temporal.

I'll just state on the record that I"m kinda feelin' @timrwood's properties here.

from proposal-temporal.

On the subject of "is" prefixes, I did an analysis of APIs across ES and the web platform and came up with w3ctag/design-principles#53. It's a little case-by-case, but probably they should only be used on methods, not on properties.

from proposal-temporal.

The threeten get method prefix should be omitted, because its quite uncommon for javascript.

I do agree in general, but is it true that it's uncommon for javascript? For example, the existing Date object has them.

Or is it a context clue for mutability? As in, if you see getFoo, do you expect setFoo to exist? And if setFoo exists, do you expect mutation?

from proposal-temporal.

I do agree in general, but is it true that it's uncommon for javascript? For example, the existing Date object has them.

Interesting point, the definition of getters seems to be not consistent in the javascript world. The javascript spec is using accessor properties, like Array.length or Map.size and methods with a get prefix like for Date.getHours(). Some js libraries like moment or socket.io omit the get prefix for getter function e.g. moment().hours().
To be closer to the javascript spec it might be the better choice either using read-only properties or the get prefix for accessing properties.

And if setFoo exists, do you expect mutation?

Yes, I expect mutation when I see a setter pattern and I do not expect that a setFoo is returning anything.

from proposal-temporal.

do agree in general, but is it true that it's uncommon for javascript? For example, the existing Date object has them.

It is worth considering that the existing Date object predates ES5 getters and setters, which means that at this time you only had the choice between having getFoo()/setFoo(foo) methods of moment-style foo()/foo(foo). Since the former can probably be optimized by JS engines a little better it might make sense to opt into something like that. Since we do have ES5 getters and setters now though we should probably use that instead, or at least the getters given that we are talking about an immutable API.

As in, if you see getFoo, do you expect setFoo to exist? And if setFoo exists, do you expect mutation?

yes, from using other APIs my naive expectation is setFoo(foo) will mutate and withFoo(foo) will create a new instance with that change.

from proposal-temporal.

In your current proposal you are using the prefix with for setting a value and for combining an object with another.

The latter is named at in threeten. I would prefer to use at eq date.atTime(time) because

• it clearly separates the two cases (with returns the same domain and at returns a different domain)
• it reads much nicer
• and because at is the counterpart to to

from proposal-temporal.

Can we close this now? I think we are beyond this and have pretty much decided on readonly properties (aka ES5 getters).

from proposal-temporal.

Yes. Thanks.

from proposal-temporal.