The pipe solution seems OKish - thanks for the suggestion!

Martin

On Tuesday, 13 September 2016 20:03:14 UTC+2, Nick H wrote:
>
> 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] 
> <javascript:>> 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] 
>> <javascript:>> 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] <javascript:>.
>>> 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.

Reply via email to