Shorthand methods for States about fusion

[raphtalia]

Proposed implementations

• Metamethods: c8fa19c
• Tables: de4b67e

[dphfox]

I'd prefer to avoid metatables if possible - I don't suspect they're necessary here.

[raphtalia]

Would having the methods for tables be acceptable?

[dphfox]

I'm generally doubtful that this would be a good addition to the API. I did experiment with this kind of thing previously in a much earlier prototype, however it tended to make code a lot more confusing as state objects and constant values would be much easier to mix up by accident.

For example:

local constant = 25
local state = State(10)

local target = State()

target:set(constant + 2) -- just a regular addition
target:set(state + 25) -- this could implicitly run other code, register dependencies and other magic!

My general approach with the design of Fusion's API is that objects should look the way they behave. If you're using function call syntax, the thing you're calling should be a function. If you're using table indexing syntax, the thing you're indexing should be a table. That sort of thing.

I usually find that mixing up the syntax introduces unintuitive and hard to track bugs and performance issues. For example, if you're indexing something that looks like a table, you might not expect it to go run some code elsewhere, and so you could make things laggy if you did that too often.

To cover every metatable case, it would also require the addition of a notable amount of code to the Fusion codebase. That could would have to be unit tested, benchmarked and maintained.

Finally, I don't really see how this would benefit users greatly. As I mentioned in another issue (#12 (comment)):

Generally, when I propose a new API or evaluate a suggestion for an API, I look to these points to see whether it's worth adding:

• Does it allow the expression of imperative code in a more declarative style?
• Does it help avoid suboptimal code and provide useful optimisation by default, such as caching or lazy evaluation?
• Does it allow the library to handle certain parts of code that are very easy to mess up and introduce bugs into?
• Does it make code that isn't currently self evident easier to read?

These aren't strict points, but rather points for consideration. This is roughly the thought process I follow to try and disambiguate between 'kitchen sink' APIs and stuff that would generally be useful for developers to leverage.

The existing way of doing things seems perfectly clear and easy to read, to my eyes at least:

counter:set(counter:get() + 1)

Especially considering all of the above points, I don't think there's much utility in shortening it:

counter:set(counter + 1)

In addition, I see a possibly competing use case where you might also want to use metamethods - when deriving computed objects from state objects. For example:

-- the current way of doing things
local numCoins = State(50)

local ui = New "TextLabel" {
    Text = Computed(function()
        return "You have " .. numCoins:get() .. " coins."
    end)
}

-- your syntax, where metamethods implicitly cast the state object to the value it stores
local numCoins = State(50)

local ui = New "TextLabel" {
    Text = Computed(function()
        return "You have " .. numCoins .. " coins."
    end)
}

-- a competing syntax, where metamethods implicitly construct computed objects
local numCoins = State(50)

local ui = New "TextLabel" {
    Text = "You have " .. numCoins .. " coins."
}

The way that I see things, the last two examples are unclear as to what exactly is going on. The creation and manipulation of state and computed objects are masked. Only in the first example is it clear that we're constructing a computed object that gets the value of the state object and manipulates it.

For these reasons, I don't think it's worth pursuing this feature request.