3 ms·

> The app is the object, and the various URL handlers are its state. There were a lot of assertions in this article that rubbed me wrong, but this one was part

> The app is the object, and the various URL handlers are its state. There were a lot of assertions in this article that rubbed me wrong, but this one was particularly egregious. Handlers are behavior. They handle something. This feels like the kind of article I would've written early in my career when I was getting really clever with stuff and starting to be able to question the way I understood the world of programming.

weego 3y ago
The article even displays clearly that the URL handlers are not state. They're the contracts that help negotiate state.
robertlagrant 3y ago
I think it's saying that the state of the app object itself is the configuration of the linkage between paths, verbs and handler functions, and that's why it's worth making an app an object.
musingsole 3y ago
The Handlers implement behavior, sure. But from the perspective of the `app` object, the handler function objects are state. You can tell, because `app` is an instance of the Flask class and the Handlers are added to the instance by way of a function call. So, Handlers are functions that "handle something", but they are also part of the app object's state, not its behavior.
- kiviuq 3y ago
  By that definition an app could never be stateless ?
- BeefWellington 3y ago
  That's a very oversimplified view of handlers. An alternate view might be: Handlers are functions that are part of the app object's state, which alters the app's behavior. In the majority (possibly overwhelming majority) of the cases this is true. The purpose of Handlers and similar Publisher/Subscriber patterns is effectively to change application behavior when they are configured.
  - musingsole 3y ago
    > Handlers are functions that are part of the app object's state, which alters the app's behavior. I find that phrasing very fair.
naasking 3y ago
> There were a lot of assertions in this article that rubbed me wrong, but this one was particularly egregious. Handlers are behavior. They handle something. class App { public IHandlerFoo Foo; // routed as /app/Foo public IHandlerBar Bar; // routed as /app/Bar ... } ... App.Foo = new HandlerFooInstance(...); ... Foo, Bar, etc. can evolve under an app's state changes, so the handlers to invoke are states of the app. They implement behaviour too, yes, but the original wording isn't wrong either.

weego 3y ago

The article even displays clearly that the URL handlers are not state. They're the contracts that help negotiate state.

robertlagrant 3y ago

I think it's saying that the state of the app object itself is the configuration of the linkage between paths, verbs and handler functions, and that's why it's worth making an app an object.

musingsole 3y ago

The Handlers implement behavior, sure. But from the perspective of the `app` object, the handler function objects are state. You can tell, because `app` is an instance of the Flask class and the Handlers are added to the instance by way of a function call. So, Handlers are functions that "handle something", but they are also part of the app object's state, not its behavior.

kiviuq 3y ago
By that definition an app could never be stateless ?
BeefWellington 3y ago
That's a very oversimplified view of handlers. An alternate view might be: Handlers are functions that are part of the app object's state, which alters the app's behavior. In the majority (possibly overwhelming majority) of the cases this is true. The purpose of Handlers and similar Publisher/Subscriber patterns is effectively to change application behavior when they are configured.
- musingsole 3y ago
  > Handlers are functions that are part of the app object's state, which alters the app's behavior. I find that phrasing very fair.

naasking 3y ago

> There were a lot of assertions in this article that rubbed me wrong, but this one was particularly egregious. Handlers are behavior. They handle something. class App { public IHandlerFoo Foo; // routed as /app/Foo public IHandlerBar Bar; // routed as /app/Bar ... } ... App.Foo = new HandlerFooInstance(...); ... Foo, Bar, etc. can evolve under an app's state changes, so the handlers to invoke are states of the app. They implement behaviour too, yes, but the original wording isn't wrong either.