Composable, value-backed accessors

Accessors to the rescue!

					class C {
						#foo = 1;
						get foo () {
							return this.#foo;
						}
						set foo (v) {
							this.#foo = v;
						}
					}
				

					class C {
						foo = 1;
					}
				

Ahem, have you heard about the [grouped and auto-accessors proposal](https://github.com/tc39/proposal-grouped-and-auto-accessors)?

Yes, and I’ll get to it soon, please bear with me!

Can we fix accessors while we’re at it?

Accessors use the first model

• Most use cases are actually backed by a "real" data property
• Yet accessors require all the "plumbing" to be rebuilt before any additional functionality can be layered over it

Example: Data validation

Use case: Throw if `n` is not a positive number

			class C {
				n = 0;
			}
			

			class C {
				#n = 0;
				get n () {
					return this.#n;
				}
				set n(v) {
					if (!(v >= 0)) {
						throw new TypeError("…");
					}
					this.#n = v;
				}
			}
			

Signal Noise

Problem statement 2

Can we improve signal-to-noise ratio?

Ahem, the [grouped and auto-accessors proposal](https://github.com/tc39/proposal-grouped-and-auto-accessors) already does this and is Stage 1 and part of decorators!

Yes, on that…

			class C {
				#n = 0;
				get n () {
					return this.#n;
				}
				set n(v) {
					this.#n = v;
				}
			}
			

				class C {
					accessor n = 1;
				}
			

✅ Excellent signal-to-noise ratio!

Is “accessor” the right framing?

• For the simple case, accessors are an implementation detail.
• User intent is not "I want an accessor" unless there is logic.

Problem statements

1. We need a high signal-to-noise ratio way to define the data properties that are part of a class' public API
2. Additive accessor use cases are common enough to deserve better DX
3. There are good reasons to solve these problems together

Why solve them together?

1. Public data properties often evolve into additive accessors
2. Solving them together productively constrains the solution space and prevents language clutter
3. For this to work, it needs to become universal. For it to become universal, it needs to provide enough value.

Please hold off on syntax bikeshedding!

Any and all syntax shown is meant to be illustrative

• Can ship independently
• Base: desugars to a regular accessor
• Layers: new descriptors? built-in decorators?

Prior art Swift property observers

			class StepCounter {
				var totalSteps: Int = 0 {
					willSet(newTotalSteps) {
						print("About to set totalSteps to \(newTotalSteps)")
					}
					didSet {
						if totalSteps > oldValue {
							print("Added \(totalSteps - oldValue) new steps")
						}
					}
				}
			}
		

h/tThanks HE Shi-Jun for the example!

					class C {
						#foo = 1;
						get foo () { return this.#foo; }
						set foo (v) { this.#foo = v; }
					}
				

					class C {
						_foo = 1;
						get foo () { return this._foo; }
						set foo (v) { this._foo = v; }
					}
				

					class C {
						[foo] = 1; // symbol
						get foo () { return this[foo]; }
						set foo (v) { this[foo] = v; }
					}
				

				class C {
					propertydata foo = 1;
				}
			

• This is the one we need for most public class properties
• Eliminate boilerplate + cognitive overhead of naming another property
• Values stored in an internal slot that is not accessible outside accessor methods

Additional advantages of using built-in decorators

• Low-fi, polyfillable way to test the waters. Syntax always a later possibility if there’s demand.
• Can extend to non-property values (e.g. validate function arguments!)
• Even more motivation for implementors to support decorators 😉

With grouped accessors

				class C {
					property n = 0;
					validate n (v) {
						return v >= 0;
					}
					normalize n (v) {
						return Number(v);
					}
				}
			

			class C {
				property n {
					validate (v) {
						return v >= 0;
					}
					normalize (v) {
						return Number(v);
					}
				} = 0;
			}
		

Recap of previous discussion

• Strong consensus against solving composable accessors via syntax
• Strong consensus that auto-accessors are largely sufficient for public class data properties
• Consensus that solving composable accessors via built-in decorators is worth exploring
• Tooling support brought up as an additional benefit of standardized functionality for this.
• Mild interest in exploring alias accessors for delegation/forwarding use cases

Additional advantages of using built-in decorators

• Low-fi, polyfillable way to test the waters. Syntax always a later possibility if there’s demand.
• Can extend to non-property values (e.g. validate function arguments!)
• Even more motivation for implementors to support decorators 😉

During the break…

I'm looking at my accessors usage, and they are (numbers are not measured): - 75% "property forwarding" - 15% lazy initial computation - 10% validation - 5% other — Nicolò Ribaudo

Changes before moving to tc39/

1. Remove value-backed accessors and work with Ron Buckton to explore potential improvements to auto-accessors instead.
2. Focus this proposal on composable accessors and split into two proposals:
   1. Composable accessors via built-in decorators
   2. Alias accessors

Composable accessors via built-in decorators

				import isFoo, hasBar from "./validators.js";
				const { validate, lazy } = SomeObject;

				class C {
					// Signature tentative, do not 🚲shed!
					@validate(isFoo, hasBar) accessor foo;

					@lazy accessor foo {
						get () {
							return expensiveComputation();
						}
					}
				}
			

Alias accessors

Problem statement: Alias accessors are a particularly large class of accessor use cases and may be worth exploring separately, as they are more likely to need syntax for reasonable DX and to access privates.

				class C {
					// Indicative syntax, do not bikeshed
					alias foo = #foo.value;

					alias bar = #internals.bar {
						get;
						#set;
					}
				}