How about this:
type alias Customer =
{ id : Int
, name : String
, height: Float
}
customerDefaults = { name = "", height = 0.0 }
newCustomer : Int -> { a | name: String, height: Float } -> Customer
newCustomer id opts =
{ id = id
, name = opts.name
, height = opts.height
}
customers =
[ newCustomer 1 { customerDefaults | name = "Bill" }
, newCustomer 2 { customerDefaults | height = 2.0 }
]
On Wed, Sep 14, 2016 at 4:41 PM, Martin Cerny <[email protected]> wrote:
> 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]> 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.
>
--
Jaap Bouma
Oosterstraat 9
8011 GM Zwolle
06 2951 2694
--
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.
