Onorio: Your eyes are bad. it's struct vs stuct! (struct bang). On Tue, May 24, 2016 at 5:26 PM Onorio Catenacci <[email protected]> wrote:
> I'm +1 with Peter on this. I think having to explicitly call out required > fields is more in keeping with existing syntax and maybe a little less > error-prone. > > That said, I think the idea of allowing required fields is a good one. > > By the way--maybe because it's been a long day and I"m tired but I don't > follow this point: > > The Kernel.struct/2 function, used to build structs dynamically, won't > check for required keys. Kernel.struct!/2 should be used if you want to > check for required keys (and also check that no extra keys are given) > > You mention Kernel.struct/2 in both cases? Or are my eyes bad? :) > > -- > Onorio > > > On Tuesday, May 24, 2016 at 7:35:46 PM UTC-4, Peter Hamilton wrote: > >> I am not a fan of the proposed signature. Generally when we have multiple >> clauses of different arity, we try to make them purely extensions of the >> first. In the proposal, we go from (fields) to (optional_fields, >> required_fields). While one could say that it's really (optional_fields) to >> (optional_fields, required_fields), I think that's changing the semantics >> of the current signature, which to me is all the fields. I will submit, >> however, that this is a bit subjective and realistically the same in >> practice. >> >> I would propose instead: >> >> defstruct [age: nil, name: nil], required: [:name] >> >> It not only maintains semantic backwards compatibility, but there isn't >> an implicit meaning behind the two different arguments. It's very clear >> that we have a list of arguments then an explicit list of required fields. >> >> On Tue, May 24, 2016 at 4:26 PM José Valim <[email protected]> >> wrote: >> > To clarify, both :age and :name fields will be present in the underlying >>> User struct/map. The proposal is only about fields which must be enforced >>> when building the structure. >>> >>> We will likely need better names than optional/required. >>> >>> *José Valim* >>> www.plataformatec.com.br >>> Skype: jv.ptec >>> Founder and Director of R&D >>> >>> On Wed, May 25, 2016 at 1:17 AM, José Valim < >>> [email protected]> wrote: >>> >>>> Hello everyone, >>>> >>>> I would like to propose an extension to defstruct that will require >>>> certain fields to be given when expanding it. Here is an example: >>>> >>>> defmodule User do >>>> >>>> defstruct [age: nil], # optional >>>> >>>> [name: nil] # required >>>> >>>> end >>>> >>>> >>>> With this feature, %User{} will fail as the :name field was not >>>> specified. %User{name: "foo"} or %User{name: nil} will both work as >>>> expected. The main use case is to make sure all important fields are set >>>> when building the data. For example, we can use such fields in the new date >>>> time types to enforce proper data representation. >>>> >>>> *Extra notes* >>>> >>>> 1. The required fields are given as second argument to defstruct as the >>>> API must remain backwards compatibility >>>> >>>> 2. The fields are required only when building structs. Matching will >>>> always work without specifying any field, for example: %User{} = user >>>> >>>> 3. The Kernel.struct/2 function, used to build structs dynamically, >>>> won't check for required keys. Kernel.struct!/2 should be used if you want >>>> to check for required keys (and also check that no extra keys are given) >>>> >>>> 4. defexception will leverage the same functionality >>>> >>>> *Implementation* >>>> >>>> Implementation-wise, structs will now defined a __struct__/1 function, >>>> besides the regular __struct__/0 function. It has not been decided yet how >>>> such function will behave given it must work both for compile-time >>>> (%User{}) and runtime (struct! User, %{}) checks. >>>> >>>> *Feedback* >>>> >>>> Now it is your turn. :) >>>> >>>> *José Valim* >>>> www.plataformatec.com.br >>>> Skype: jv.ptec >>>> Founder and Director of R&D >>>> >>> >>> -- >>> 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/CAGnRm4%2B5b%2BxxcvMOL-n6XyJ4mcQcumTU5B0AhjaTuc7qk-0P1g%40mail.gmail.com >>> <https://groups.google.com/d/msgid/elixir-lang-core/CAGnRm4%2B5b%2BxxcvMOL-n6XyJ4mcQcumTU5B0AhjaTuc7qk-0P1g%40mail.gmail.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/bede9a4c-8428-4447-bda1-c77eccd64893%40googlegroups.com > <https://groups.google.com/d/msgid/elixir-lang-core/bede9a4c-8428-4447-bda1-c77eccd64893%40googlegroups.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/CAOMhEnyNx3O%3D7QEk3Cw-Spvqaw6Ve1RpozVE6t_nsxQ8sxFU6Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
