OK, this is a more complex issue than what I had in mind. If you have a small number of desired initializations (maybe 2 or 3 cases besides defaultCustomer), I think it would make sense to have multiple construction functions. But of course that won't scale at all.
On Tue, Sep 13, 2016 at 7:03 AM, Martin Cerny <[email protected]> wrote: > Hi, > thanks for the suggestion, but I think you are answering to a different > problem than the one I had in mind, I'll try to be more clear to avoid > confusion. > In my use case, I have a lot of fields, which usually can be kept with > their default values, but some of them aren't. So not all customers need > names. Maybe a better example of the code I want to write would be: > > type alias Customer = > { id : Int, > name : String , > occupation : String, > nickname : String, > height : Float, > -- Lots of other stuff > } > > > defaultCustomer : Int -> Customer > defaultCustomer id = > { id = id, > name = "", > occupation = "", > nickname "N/A", > height : 1.6, > -- lots of other initialization > } > > [ > { (defaultCustomer 1) | name = "Smith", occupation = "Clerk" }, > { (defaultCustomer 2) | name = "Jones" } > { (defaultCustomer 3) | nickname = "R2-D2", height = 0.5 } > ] > > > > Martin > > > > > On Monday, 12 September 2016 17:50:21 UTC+2, Nick H wrote: >> >> In this case, I think the best thing to do would be to make a >> construction function that takes a name as well as an id. >> >> defaultCustomer : Int -> String -> Customer >> defaultCustomer id name = >> { id = id, >> , name = name, >> -- lots of other initialization >> } >> >> You constructor function should never return an incomplete/invalid >> record. If your customers always need names, make sure they always get >> names! >> >> >> >> On Sun, Sep 11, 2016 at 4:44 AM, Martin Cerny <[email protected]> wrote: >> >>> Hi, >>> hope its polite to bump up an old thread like this - if not, please >>> accept my apologies. I have been struggling with the record update syntax >>> for a while and wanted to share another use case which I think could be >>> made better. >>> So let's say I want to populate a list of objects of the same type which >>> have a lot of properties, most of which are kept default, e.g. >>> >>> type alias Customer = >>> { id : Int, >>> Name : String , >>> -- Lots of other stuff >>> } >>> >>> and I have a "constructor" function to build instances with default >>> values, but never forget to fill in the id, e.g. >>> >>> defaultCustomer : Int -> Customer >>> defaultCustomer id = >>> { id = id, >>> Name = "", >>> -- lots of other initialization >>> } >>> >>> now I would like to write things like >>> [ >>> { (defaultCustomer 1) | Name = "Smith" }, >>> { (defaultCustomer 2) | Name = "Jones" } >>> ] >>> >>> Which is not possible. >>> >>> Now I have two options: >>> a) do not use a "constructor" and always write the records in full (not >>> nice since they have a lot of fields which are mostly left default) >>> b) just have a template defaultCostumer : Customer and hope I will never >>> forget to fill in the id (used in messages) >>> c) have a long "let" clause before defining the list >>> >>> Neither of which seems nice. >>> >>> I'll probably go with b), but if anyone has a nice suggestion how to >>> enforce filling in a record in this way with the current syntax it would be >>> very welcome. >>> >>> And thanks for the work on elm - I am learning it and having fun with it! >>> >>> Martin >>> >>> >>> >>> >>> >>> but I tried to figure out where on GitHub should this be discussed and >>> kind of failed... >>> (is it https://github.com/elm-lang/elm-plans/issues/16 or >>> >>> On Saturday, 26 July 2014 18:08:22 UTC+2, Jeff Smits wrote: >>>> >>>> Yeah, I really want this feature. But I guess I forgot about the "code >>>> comparison". >>>> >>>> @Evan: can you say more concretely what kind of code comparison you >>>> want to see before moving forward on this feature? >>>> >>>> On Sat, Jul 26, 2014 at 2:26 PM, David Sargeant <[email protected]> >>>> wrote: >>>> >>>>> Seems a little strange that the following does not work: >>>>> >>>>> { {} | attrs = [1] } >>>>> >>>>> I know it's not really useful, but I guess it goes back to the issue >>>>> of allowing arbitrary expressions to the left of the vertical bar. >>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Elm Discuss" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to [email protected]. >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Elm Discuss" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Elm Discuss" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
