Which all reasons? I see only one possible reason, which is “composability”. If that’s the case, I’m not convinced it’s a good enough reason.
The approach with attributes seems clunky to me. A struct def is spread over three separate expressions, which must appear in some particular order. First the attributes of the struct appear, and only then the struct. That reads funny. Also, it’s a stretch, but it’s possible that a sloppy programmer separates these expressions, say by inserting a multiline comment, a typespec, or even something completely unrelated. Then it becomes harder to spot the complete specification of the struct. Another issue is that this “composability” is based on setting a piece of info into some context. That’s seems to me more like a mutable approach, and it suffers from same pitfalls. Say I want to move the struct to another module, I have to pay attention to move all three expressions (which might be separated by some other not necessarily struct related stuff). Or say in my macro which defines a struct, I want to prevent some option (e.g. require). I need to work explicitly to opt-out of that (and I need to be aware of that fact in the first place). Finally, this approach might set a bad example. Other macro authors might use the same technique where plain arguments would suffice. In contrast, having these macros accept valid options as arguments allows us to specify the struct in a single expression (which IMO reads nicer). It makes the interface more explicit about what’s accepted, and it forces the authors of custom macros, such as defexception/defstruct to opt-in to those extra features. And it sets a nice example :-) I’m not saying that attribute approach is necessarily bad. But given that you mention only two examples (defexception and schema), and the extra code that would be required with the argument approach is small, I’m not sure this is a good trade off in this case. > On 25 May 2016, at 17:43, José Valim <[email protected]> wrote: > > > In fact, I wonder why is derive an attribute, and not an option? > > For all the reasons said above. :) > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/elixir-lang-core/0A95E06E-8689-4D3C-954E-17046EEBDB8E%40gmail.com. For more options, visit https://groups.google.com/d/optout.
