On Tue, Jul 25, 2017 at 3:32 AM, Erik Simmler <tge...@gmail.com> wrote:
> That said, what if we flip the question around? Given that we have
> facilities for encapsulation (unexposed types), what would we gain by
> adding a new set of concepts around mixing data/logic and syntactic sugar
> in the form of "this"? What would this enable?
>
We could have better polymorphism. For example, we could have something
like traits.
trait Stringable =
{ toString : this -> String
}
type Msg implements Stringable =
{ tags = Increment | Decrement
, toString = \this ->
case this of
Increment ->
"Add One"
Decrement ->
"Subtract One"
}
This would allow one to declare something like List Stringable that would
accept all String and objects that can be turned into a string because they
implement the Stringable trait.
We would not have to keep putting toString all over our code but rather
decide at the type declaration level how the string representation of the
type should look.
The same argument can be made for serialization too.
As far as I can see it, the prime target for this would be to implement
web-components like nodes that would be just implementations of some node
interface. Behind the scenes we would still get a single source of truth
but this single source of truth would be generated based on these
implementations. In my view, this would eliminate at least some of the
boilerplate.
--
There is NO FATE, we are the creators.
blog: http://damoc.ro/
--
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 elm-discuss+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
