Should `@signal` and `@cached` be named `@state` and `@computed`?

[justinfagnani]

@cached is a wrapper for new State.Computed(). I think a key feature missing from the name "cached" is that the getter is run as a computed signal, so the getter itself can be used in other computed signals, effects, etc.

@signal doesn't suffer from that particular problem, but as people become familiar with the signals terminology they may find @state to be more obvious in what it does.

Another option would be to combine @signal and @cached into a single decorator @signal that creates a state or computed based on the target kind. @signal accessor foo; would make a new state signal, while @signal get foo() {...} would make a new computed signal.

[NullVoxPopuli]

This reminds me, we should probably start a rational series of comments in the code about why each thing is named the way it is and why it's implemented the way that it is.

For example, and i'm not saying I'll really defend this, but @cached comes from Ember, for the same purpose as State.Computed, but I've avoided @computed because it's already a decorator used in Ember, but for explicitly-specified dep-tracking (non-auto-tracking). But it has been brought up here: https://github.com/tc39/proposal-signals/issues/20#issuecomment-1854486123

Another option would be to combine @signal and @cached into a single decorator

I actually really like this idea, and would super accept a PR implementing it.

the semantics, I think are maintained - because we're just adding certain reactive behaviors that transparently align with existing javascript concepts -- accessors and getters.