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 <mhamburg...@gmail.com> 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 elm-discuss+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
