Note, though, that struct-copy needs to be given the type of the resulting structure statically, at compile time, and "the result of *struct-expr* can be an instance of a sub-type of *id*, but the resulting copy is an immediate instance of *id* (not the sub-type)." [1] If you have a complex hierarchy of struct types (as might be the case if you're using structs in an OOP-inspired sort of way), this can get a little annoying.
Personally, I tend to end up defining helper functions to do functional update (often with optional keyword arguments to address the fields-that-stay-the-same issue). Generics in the sense of racket/generic can be helpful for this if using structs. I may then implement the helper function using struct-copy, but I can hide away its idiosyncrasies. [1] http://docs.racket-lang.org/reference/struct-copy.html?q=struct-copy#%28form._%28%28lib._racket%2Fprivate%2Fbase..rkt%29._struct-copy%29%29 On Wed, Feb 8, 2017 at 6:14 PM Alex Harsanyi <alexharsa...@gmail.com> wrote: > Structures support this style of updating: > > (struct foo (bar baz) #:transparent) > > (define one (foo "hello" 1)) > > ;; Copy all fields from "one" and update baz to 2 > (define two (struct-copy foo one (baz 2))) > > They also have immutable fields by default. > > Best Regards, > Alex. > > -- > You received this message because you are subscribed to the Google Groups > "Racket Users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
