Okay. I'm shutting up here and just tacking this onto https://github.com/elm-lang/elm-compiler/issues/1145.
On Tue, Oct 25, 2016 at 4:15 PM, Mark Hamburg <[email protected]> wrote: > Here is a very simple failure case that shows that comparing tasks isn't > necessarily safe (though it does succeed if I create two success tasks): > > import Html exposing (..) > > import Http > > task1 = Http.getString "http://somewhere"; > > task2 = Http.getString "http://somewhere"; > > main = text <| if task1 == task2 then "Match" else "No match" > > > What in this was supposed to clue me in that it might throw a runtime > exception other than the use of ==? > > Mark > > On Tue, Oct 25, 2016 at 3:18 PM, Mark Hamburg <[email protected]> > wrote: > >> I just thought of another example where the ability to test function >> equality matters: >> >> Picking up on a discussion on elm-dev regarding the new HTTP rate >> limiting logic, I thought about moving my case away from using rate limit >> and instead just creating the model code to manage buffering HTTP requests. >> This is pretty easy to do with the new Http.Request. (It would also have >> been straightforward with tasks but might have felt a bit less natural.) >> But to handle things correctly, I need to test Http.Request for equality. >> Is that safe to do or does it incorporate a function somewhere — e.g., in a >> decoder — and hence does comparing it for equality risk a runtime >> exception? How would I know without looking inside the implementation of >> Http.Request and potentially everything it references? >> >> Mark >> >> (*) The specific use case I'm thinking about is a variation of >> RemoteData.WebData to support setting the desired request as a way to drive >> it. Thinking about it further, tasks might be even better since they exist >> at a lower level but similar concerns over equality testing generating >> runtime exceptions would apply. > > > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
