@art, I disagree about adding arbitrary expressions between { and |. You
should use a let-binding for something like *Array.get (offset + i)
arrayOfRecords |> Maybe.withDefault defaultRecord*.
I know this is supposed to be pain points, not solutions, I'm going to try
to coalesce some of the syn
It's not a huge deal but other strongly typed languages definitely allow
arbitrary expressions in record update syntax.
# type t = { a : int ; b : float } ;;
type t = { a : int; b : float; }
# let emptyT () = { a = 1 ; b = 3.0 } ;;
val emptyT : unit -> t =
# let x = { (emptyT ()) with a = 7
I just had a senior engineer on my team ask me whether it was really the case
that putting a qualified name or a field access into the beginning of a record
update would fail to compile. His examples were much like the other examples
from this thread, but I'm noting this here to make clear that
Great post Mark - I've been working on a project lately and setters are
fast becoming my #1 pain. I can relate to every one of those points you
outlined, and you said it better than I could.
On Thursday, March 9, 2017 at 11:09:22 PM UTC, Mark Hamburg wrote:
>
> I got asked for non obfuscated/si
I got asked for non obfuscated/simplified examples, so let me run through
some more realistic code. I would pull from our own codebase but we've
often contorted ourselves away from these patterns because they are so ugly
so I can't just grab existing code.
Imagine having a style element that inclu
Martin, Mark: do you have concrete examples of painful record updates? It
sounds like with the thought you're putting into this, surely you're
experiencing some significant pain. Examples, the more real the better, would
be super!
If you have suggestions, it would be more helpful to spin off a
Nothing special and I'm a beginner so I might be doing something stupid but
I'm attempting to have some nested data in my model and this is the current
state of one of my update functions which is fairly painful.
update : Business.LocationList.Model.Msg -> Model -> ( Model, Cmd
Business.Model.M
> Either you end up with 50 messages in the model update or you end up with
50 files for each record that can be updated.
There is no need to split or combine messages because of update function.
The other solution is to create a `mapX` function for each nested structure
and use it for each update
On Friday, March 3, 2017 at 8:45:01 AM UTC-8, Mark Hamburg wrote:
>
> Our codebase suffers from this as well.
>
Mark, can you post some examples of painful code? As in, not just what you
wanted to write but couldn't, but what you ended up writing that's still
painful.
Real code is much more use
Our codebase suffers from this as well. And unlike what one of the follow ups
noted, this isn't an issue of wanting to add fields. Rather, it's an issue of
not being able to use an expression in the first part of the record update. In
this case, one doesn't even need a general expression but jus
Here's an example from elm-style-animation, looking at animating a list of
something like cards.
type alias Model =
{ cards : List Card }
type alias Card =
{ content : String
, imageSrc : Msg
, likes : Int
, style : Animation.State
}
... basic update. Doesn't loo
Can we express these in terms of examples of real-world code that is
currently painful? That's really the key here. :)
On Fri, Mar 3, 2017, 4:18 AM 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:
> Another one I have run into, is when selecting just one field from a
> record
12 matches
Mail list logo