I like Ciarán Walsh's idea of `required_keys`. I don't have a strong preference for an attribute or an option to `destruct`
I think this proposal overall would be a great addition! On Wednesday, May 25, 2016 at 1:31:01 PM UTC-4, Saša Jurić wrote: > > > > In both cases you need to understand the semantics of derive and > require. For module attributes though, you do need to know how these things > tie in together. It is the trade-off between restrictive and composable. > > I don’t see that trade-off here. > > defstruct which takes parameters is composable. Any macro that uses > defstruct can take the same parameters (or some subset), and pass them to > defstruct, and it will work. It can also take some different parameters, > and derive from them the ones that needs to be passed to defstruct. > > The “composability” of module attribute is really an equivalent of a > global var. One expression sets something into the context, and another, > seemingly unrelated expression depends on it. Therefore, it works out of > the box for anyone who happens to use the same expression. But I’d say it’s > more like a shortcut, rather than something I’d choose as the first option. > I’m not saying it’s always a bad approach, but I’d expect some strong > reasons for choosing it. I don’t see such reasons here. > > A trade-off which IMO does exist is opt-in vs opt-out. With params, each > macro writer needs to explicitly allow the supported options. With module > attributes, these are implicitly available without writing a single line of > code. > It’s worth pointing out that this trade-off revolves around writers of > macros which use structs. For users of macros, I think the difference > between two approaches is mostly aesthetic. > > Since I don’t expect macros written on top of defstruct are such common > case, a more complicated, less idiomatic interface backed with attributes > is IMO not justified here. > More often than writing such macros, I define structs, and having the > standard interface (macro which takes params) is IMO better suited for > that. > > -- You received this message because you are subscribed to the Google Groups "elixir-lang-core" group. To unsubscribe from this group and stop receiving emails from it, send an email to elixir-lang-core+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/a9bd4321-4e3f-49a7-84af-95951e5fdb29%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
