Comment by _0w8t | Hacker News Reader

Comment by _0w8t | Hacker News Reader

Parent Full thread

What is nicer to test and maintain?

To test render() in the clicked state with the explicit state I can call it with the corresponding state. With the implicit state at the very least I have to write a driver to run render() into the clicked state and then test the next state transition.

To understand the effects of the code on other parts of the application with the explicit state it is sufficient to look at the definition of the state. The implementation of render is only relevant if one wants to look at details. With the implicit state I have not only understand what render() is doing, but also understand how to properly call it from other parts of application. I.e. what happens when the render is called the third time?

Testing could be much easier for the implicit state version. I've not defined it, but you are assuming things about how the render function or the implicit state behaves.

In my hypothetical implicit state framework - A widget is composed of a sequence of steps, each of which is an independent widget. So it's easy to write invariant properties for each step -

For (text "String") it's guaranteed that the widget never returns a value or raises an event. i.e. the type is

    forall a. Widget a.

So the issue of calling render a third time never arises.

The explicit version we can understand how it works just by looking at it. The implicit version we need knowledge about how your hypothetical framework works.

Of course you need to understand how the framework works. But that's a fixed cost vs. having to understand a program from scratch everytime when your framework is not clear or powerful enough.

Would you also say using "goto" is easier because it's a simple jump, vs. having to understand how while/for loops work?

Reply on news.ycombinator.com