Thanks Peter! Figured I had to be missing something. On Tue, May 24, 2016, 8:55 PM Peter Hamilton <[email protected]> wrote:
> 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 a topic in the > Google Groups "elixir-lang-core" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/elixir-lang-core/rW8c3_xSVCg/unsubscribe > . > To unsubscribe from this group and all its topics, 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 > <https://groups.google.com/d/msgid/elixir-lang-core/CAOMhEnyNx3O%3D7QEk3Cw-Spvqaw6Ve1RpozVE6t_nsxQ8sxFU6Q%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/CAP%3DvNq8Xgz4qwY4cpRcC0%2BqMU4PTNqZaUpuJATKBxgjFVg8Ocw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
