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.
