Another solution might be to define some setters, so that you could write something like:
[ defaultCustomer 1 |> setName "Smith" |> setOccupation |> "Clerk", defaultCustomer 2 |> setName "Jones", defaultCustomer 3 |> setNickname "R2-D2" |> setHeight 0.5 ] Unfortunately, defining all those setters is verbose. But I often find them much nicer to work with than Elm's record-updating syntax. I am willing to jump through a lot of hoops in order to use pipe operators :-) On Tue, Sep 13, 2016 at 10:49 AM, Nick H <[email protected]> wrote: > 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.
