The one thing I don't like about using options with defstruct is that I
tend to define my structs with the keyword list syntax, defining default
values - if I want to do that *and* define required fields, I now have to
wrap the definition of the fields+defaults in a list, i.e.:
defstruct [foo: "bar",
baz: :qux,
bar: nil], required: [:foo, :baz]
Granted, that's not a big deal, but I like the following much better:
@required [:foo, :baz]
defstruct foo: "bar",
baz: :qux,
bar: nil
That said, I don't disagree with your reasoning, but I think the ship has
already sailed with regards to precedent (i.e. `derive`).
Paul
On Wed, May 25, 2016 at 11:35 AM, Saša Jurić <[email protected]> wrote:
> 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
> <https://groups.google.com/d/msgid/elixir-lang-core/0A95E06E-8689-4D3C-954E-17046EEBDB8E%40gmail.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>
--
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/CAK%3D%2B-TvQ1DzXU-VX7Br%3DDMG750eFaqH4OebqTghfhz6Vf47aHw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
