I just made an experiment with having the compiler generate a representation of
an Elm type that could then be used to automatically generate for instance
Jason encoders and decoders.
The compiler extension is not done but you can see the experiment at
That looks a bit clumsy to use from JS land though... if you want to read
numberOfDoors you'll have to loop through all the fields to find the
correct one? The format has to be both correct and easy to work with.
fredag 3. mars 2017 19.42.52 UTC+1 skrev Rupert Smith følgende:
>
> On Friday,
On Friday, March 3, 2017 at 4:35:00 PM UTC, Eirik Sletteberg wrote:
>
> type alias Car =
> { numberOfDoors: Int
> }
>
> type alias Plane =
> { maxSpeed: Int
> }
>
> type Transport = Walk
> | Ride Car
> | Fly Plane
>
Or could be mapped to something that can be described with a
On Fri, Mar 3, 2017 at 6:18 PM, 'Rupert Smith' via Elm Discuss <
elm-discuss@googlegroups.com> wrote:
> On Friday, March 3, 2017 at 3:29:34 PM UTC, Peter Damoc wrote:
>>
>> It makes sense to focus on other issues that are more important BUT,
>> people are having enough troubles with boilerplate
> ['Ride', {
> numberOfDoors: 4
> }]
>
> or ['Fly', {
> maxSpeed: 1000
> }]
Personal experience: I think that tends to be too confusing when the object
(inevitably) gets separated from the list. It all needs to be in one piece. I
like to use fields beginning in underscores for this, like
type alias Car =
{ numberOfDoors: Int
}
type alias Plane =
{ maxSpeed: Int
}
type Transport = Walk
| Ride Car
| Fly Plane
Could be encoded as [name, encoded] or just [name] if it's only an
identifier without a value.
So they would be encoded as
['Walk']
or
['Ride', {
On Friday, March 3, 2017 at 3:29:34 PM UTC, Peter Damoc wrote:
>
> It makes sense to focus on other issues that are more important BUT,
> people are having enough troubles with boilerplate introduced by decoders
> that this could easily be considered a priority.
>
+1 from me, just for the
I could have phrased this more carefully. I meant that we can't blithely pass
random strings out to JavaScript without some formality of defining that API.
My point about type systems is only salient so far as to say "JS doesn't have
union types so there's no direct mapping."
> It makes sense
On Fri, Mar 3, 2017 at 4:38 PM, Brian Hicks wrote:
> It makes sense (at least to me) that this isn't supported. Elm has a much
> different type system than JavaScript.
>
I respectfully disagree.
It makes sense to focus on other issues that are more important BUT, people
It makes sense (at least to me) that this isn't supported. Elm has a much
different type system than JavaScript. I could see converting them in a
standard way, but that's a ways off yet.
For now, try encoding to a Json.Encode.Value - you can send that through a
port, and it has a standard
10 matches
Mail list logo