5 ms·

If it was a purely functional interaction, shouldn't the same request always get the same response? In reality a lot of non-pure IO stuff tend to be the main p

• jrockway 16y ago
  If it was a purely functional interaction, shouldn't the same request always get the same response? Yes. This is why things like Rail's "flash" breaks the Internet... or at least your web app.
  • bobfunk 16y ago
    Well, each time I go to twitter.com I hope to see something slightly different than last time and that's not part of the internet being broken.
    • gattone 16y ago
      Yes, but each time you go, the input data (like the microsecond since 1970) is different.
      • jrockway 16y ago
        No. If Twitter were purely funtional, which it is not, twitter.com would be a pointer to twitter.com/<state>, where twitter.com/<state> changed every time someone tweeted. twitter.com/234987kdsjlhfsad would always be the same page. It's the auto-redirect to the current state that makes twitter.com appear to change. If you use git, it's like the HEAD reference. It's a pointer to the immutable commit. The reference itself is mutable.
  • po 16y ago
    Each request should get the same "logical" response. There is nothing wrong with the content varying with each request. A resource that represents "The last 10 items processed" will always contain just that, even if the response is different at the html level. This is why cache-invalidation is important. A resource can also be composed of parts of other resources. For instance, you can have an order resource which is composed of item resources that each have their own url. I think the rails flash is usually used to send a user a message which will only be seen once on the very next request. Think of the message as a resource that isn't important enough to get it's own url, and every resource as a composite of the actual item they are looking for and an optional "message" resource. The message resource isn't important enough to store into permanent storage. It could be stored into the db backend and then loaded up on the next request, and then deleted once the user has seen it. In practice that's not practical so it's kept in memory. I don't think it breaks the internet at all.
    • jrockway 16y ago
      I don't think it breaks the internet at all. Consider: user submits form that loads slowly, application sets flash and slowly begins sending response. User gets bored and visits yoursite.com. Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops. State breaks the internet.
      • po 16y ago
        Flash message appears on yoursite.com and does not appear on the page that is loaded after the form is submitted. Oops. Doesn't really seem like an oops to me. State breaks the internet. You submitted a form. That presumably changed the state of the resources at that url too. The page should set the flash state when the state transition is done, not when it starts. It shouldn't matter if the user sees the message on the page after the form or from a different page altogether. What if every page had a history of all of the flash messages ever produced? You wouldn't call that "state" any more or less than the state of the objects you were trying to change in the form itself. I think the part of this you actually don't like is that the following GET implicitly deletes the state (which is why we can optimize and store it in session rather than the db). But when the state is "messages unseen by the user" then it seems reasonable to me. I think we can agree that any state where it matters what page they view the message on is probably not a good candidate for flash. I'm not even a rails programmer but I think there are better examples for the state-is-bad idea.