Rename `Signal.get` and `Signal.set` to `Signal.read` and `Signal.write`

[titoBouzout]

That's it. This may be subjective, but I believe It makes it easier to reason about things when you refer to reading and writing than getting and setting.

• It clearly separates the concept of setters/getters from tracking by read, triggering updates by writes. A getter executes a method and a read returns a value.
• Denotes a clear context of what you are referring to, this may not be the best of the examples, but lets say the user explains "I am triggering an update by getting", what do they mean? Are they reading a signal from a getter? and they cant stop the getter from triggering a read?. Another, "I cannot set the signal in the setter" vs "I cannot write to the signal in the setter"

I could probably make the point stronger by copy pasting snippets from this very same repo that includes the wording read and write:

• Ability to read Signals without triggering dependencies to be recorded (untrack)

• A Signal type which represents state, i.e. **writable** Signal. This is a value that others can **read**.

…calculated again by default when one of their dependencies changes, but rather only run if someone actually reads them.

• Solution: Disallow reading and writing any Signal from within a synchronous reaction callback

Note: This proposal does allow signals to be both read and written from computed and effect signals, without restrict…

// No signals may be read or written during the notify.

// Our computation somehow led to a cyclic read of itself.

// - The code for the callbacks (for reading signals and running watches)

// A read-write Signal .. export class State<T> {

export function setThrowInvalid**Write**ToSignalError(fn: () => never): void {

consumerAllowSignal**Writes**: false,

• Whether writes to signals are allowed when this consumer is the activeConsumer.

it("allows writes during computed", () => {

throwInvalid**Write**ToSignalError();

Link to "reads" of this repo https://github.com/search?q=repo%3Atc39%2Fproposal-signals+reads&type=issues Link to "writes" of this repo https://github.com/search?q=repo%3Atc39%2Fproposal-signals+writes&type=issues

[jeff-hykin]

IMO this is bikeshedding

[titoBouzout]

You think? To me the API surface is very important. Code reads more clearly with read/write than with get/set. Is not the typical get/set, both actions have side effects reading and writing communicates the difference properly. Also, you comment adds nothing of value. If you are not interested do something else.

[jeff-hykin]

Sorry, I did not mean for it to be a throw-away comment. I agree the API surface area and names in general are not bikeshedding.

I personally, coincidentally, find get and set more clear, because read and write are usually associated with cold storage in my experience. I don't think either get/set or read/write indicate side effects. If anything pull/push might indicate side effects more and aligns with the terminology of the design.

I'm only one vote and these things are about feedback/consensus. My estimate is the average user isn't going to find push/pull or get/set or read/write notable. But they will find stuff like not working with Async notable.

It's good you brought up the topic, I've said my piece, now it's up to others to say theirs so we can have a complete picture.

[timreichen]

get() is commonly associated with getting a value by name/key in web APIs (Map.prototype.get(key), FormData.prototype.get(name), URLSearchParams.prototype.get(name), etc.), so get() without passing a argument looks weird to me.

[trusktr]

Can we just have signal.value ("read") and signal.value++ ("write")? Much cleaner. :D

[timreichen]

@titoBouzout could you provide an explanation why this issue was closed?

[timreichen]

Can we just have signal.value ("read") and signal.value++ ("write")? Much cleaner. :D

Ref: https://github.com/tc39/proposal-signals/issues/152