Normative: Change the getters to methods #65
Conversation
Close #62 Per 2022-11-30 TC39 recommentations
|
We need to change the following test262 tests with this PR 'intl402/Locale/prototype/calendars/branding': [FAIL], |
https://bugs.webkit.org/show_bug.cgi?id=248836 rdar://problem/103041601 Reviewed by Justin Michaud. Nov 30 TC39 meeting decided to change Intl.Locale info getters to methods[1] because of object identity issue[2]. This patch aligns our implementation to this change. [1]: tc39/proposal-intl-locale-info#65 [2]: tc39/proposal-intl-locale-info#62 * JSTests/stress/intl-locale-info.js: (throw.new.Error): (shouldBe): (let.l.new.Intl.Locale.shouldBe): * JSTests/test262/expectations.yaml: * Source/JavaScriptCore/runtime/IntlLocalePrototype.cpp: (JSC::JSC_DEFINE_HOST_FUNCTION): Canonical link: https://commits.webkit.org/257449@main
|
My approval stands, but I would also like to see the names of properties that users must invoke as functions indicate that fact (and align with precedent such as Date.prototype) with a "get" prefix, especially since Locale instances already have non-function properties and it will definitely confuse practitioners if e.g. getting desired data looks like
|
|
TG2 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-12-08.md#normative-change-the-getters-to-methods-65 Conclusion: We are not clear on whether the functions should have a CC @zbraniecki @bakkot @michaelficarra @waldemarhorwat @ljharb @ptomato |
|
Soft preference for the (Arguing against myself here, but:) because Intl already omits it for the |
Exactly (elaborated further above).
Or when some properties are data getters while others must be invoked as methods, which is the case here. It's true that Map and Set already have that mix with a non-method |
|
My position is soft rejection of |
|
Those are all actual getters - methods that get are nice with the “get” prefix, since they’re a verb, which indicates function-ness. |
|
@ljharb I'm confused by your response. Can you rephrase please? |
|
@zbraniecki ”actual getters” are seemingly normal properties that magically/implicitly call a function - as such, it’s appropriate to name them as if they were properties. Things that look like functions should generally be named with a verb, since they do things - and in this case, the thing the methods do is “get” something. You’re totally right that keys/entries/values aren’t actual getters - my mistake - but i don’t think those APIs are super clearly named (nor is it new in ES6; Object.keys eg is in ES5) |
|
Thanks, I'm still a bit confused about your position here.
Which ones, in your opinion, are "actual getters" and which ones are "things that look like functions"? |
|
When i say “actual” I’m referring to whether it’s an accessor property vs a function-valued data property. A function looks like a function when you invoke it with parens. |
Can you classify using your mental model the following:
? |
|
I'm not familiar with the LocaleInfo ones, but yes, Map/Array/Set keys/entries/values are methods, but poorly named imo since they aren't verbs - they're named more like accessors (but their semantics aren't appropriate for accessors, since they return a new object every time). I don't want to repeat that pattern elsewhere if we can avoid it. |
|
Thanks, so I derive from your words that your position is that
Do you feel this position is universally accepted in TC39, is the group split, or do you think your opinion is in minority? |
|
Yep, that sounds accurate. I don't think this kind of naming question has come up before such that I have any idea what the group thinks - the naming of Object.values/entries was precedented by Object.keys, and nothing similar that I can recall has been added since ES6 (ie, with the modern process). |
|
In addition to aligning with the static Object methods (for which “methodness” is relatively unambiguous), the keys/entries/values trio constitutes an informal generic iterable collection contract shared by Array, Map and Set. On the web platform, these are joined by each interface that uses iterable, maplike, and setlike declarations, too. That generality & ubiquity impacts the calculus a bit imo? There’s nothing similarly generic about concepts like “the calendars of something”. |
There isn't indeed. But I'm struggling a mental model that says "if a method is to be shared between a range of types, then it shouldn't use the prefix, but if it's just for one type, it should". Such logic doesn't scale as the API evolves and one doesn't know how many types will reuse it when we introduce it for the first type. My position is the one derived from Rust code convention - getters shouldn't use For all other cases, universally, I believe that any getter/setter pair should be |
I agree — like ljharb had said, these examples had a particular “lineage”. I meant more that they happened to be less problematic.
Mine comes from JS + JS APIs on the web platform, where getters (in the sense of accessor property [[Get]] functions) are typically “noun-named” and methods are typically “verb-named” if they appear on meaningfully stateful objects. But there are enough exceptions that I couldn’t claim this is universal or anything.
As far as I know this would be a novel pattern for JS. It would seem very surprising to me. Where there is |
How can you predict that? It's quite common in my experience that you start with a getter and only later extend the API to have a setter. If at the time of deciding on the getter you don't know if you'll ever need a setter (this is the case here - we don't think we'll need setters, but maybe in a couple years someone will propose one?) then as API designer you're forced to see the future. Unless you want to say "not adding get* is appropriate in cases where the API designer can reasonably claim that setter for that property will never be needed". I can support such mental model. In this case, we could ask ourselves - do we see any possibility that a setter for those will be needed, and if the answer is "no", then we would go without "get" prefix. Otherwise we'd use "get" prefix to prepare for potential "set". But this feels still fragile API naming convention. |
I think this is one reason why they’re almost always either real getters or, if something prevents that like here, methods that use FWIW, in the web platform in particular, this sort of naming issue just doesn’t seem to show up much in the first place because actual getters outnumber “getX methods” by at least an order of magnitude. Web IDL “attributes” (accessors in the JS binding) that return objects are backed by internal state so that the same object is returned. I think the case for dropping |
|
Even if there were general guidance against a "get" prefix, I would still argue for having it here to improve the developer experience by more clearly differentiating which properties of a Locale instance must be invoked as methods. |
|
here is what I will do. I will keep this PR unchanged with the current name, but I will open another PR which have the name changed. So we will have two PR side by side and we will talk about in TC39 and I assume one of that will be picked (I assume the new one will be) . How about that? |
|
Another PR with also the name changes in #67 |
|
In 2023-01-31 TC39 meeting the concensus is merge PR 67 but not PR65 |
Close #62
Per 2022-11-30 TC39 recommentations