On Mon, Dec 17, 2018 at 4:08 PM Jens Axel Søgaard <jensa...@soegaard.net> wrote:
> However if you add a field to a struct foo, then you need to a new field > to all patterns matching foos. > If on the hand you used foo-bar then adding a field baz requires no > changes to the existing code. > You can avoid this issue by writing a custom match expander. If needed, you can even overload the same identifier to serve as a match expander, static struct information, and constructor function, just as `struct` would normally do. For example, if you had a struct: (struct dog (name age)) and then added a field to make it: (struct dog (name age color)) you could arrange so that, as a match pattern, (dog n a) would effectively expand to: (dog n a _) This would keep you from having to update any existing code. Doing this takes some work, even with macros to take care of the boilerplate, so it seems to make most sense when you have a struct that's part of an API (public or between parts of your project) and you want to avoid breaking backwards compatibility. In such cases I often want to abstract as much as possible anyway over how the datatype is implemented as a struct and present the nicest interface possible to client code: for example, I will often make the match pattern use optional keywords, because I don't like keeping track of the order of fields in large and potentially-changing structs. I would also note that, if you expose the struct-ness of your datatype to clients, adding a field creates a similar compatibility problem with the constructor. -- 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.
