You're right it is easy, but it also feels quite messy. I appreciate your point that the specific use-case of value is to represent a value attribute in HTML which is a string, but part of the fun of elm is that it hides a lot of implementation details in HTML and CSS, and given that you can use types for events I think it's equally reasonable to use types as values. That said, the more I think about it the more complicated it feels - how will the app know to decode those types, how will it encode them and avoid collisions with other types? It could simply use toString and an auto-generated version of fromString...Bit of a thicket, perhaps, but then again I've never designed a language feature before - just used them :-).
On Wednesday, October 26, 2016 at 5:47:25 PM UTC+1, OvermindDL1 wrote: > > That sounds like a typeclass or a HPT, neither of which are in Elm (yet?). > Passing in manual serialization/deserialization functions is easy to do > though. :-) > > On Wednesday, October 26, 2016 at 10:32:18 AM UTC-6, Martin Cerny wrote: >> >> I think this points to a more general use case. I think it would be >> useful to be able to use union types a bit like enums in other languages >> (my background is mostly Java). For example having >> >> type Role = Admin | Moderator | User >> >> it would be cool to get something like: >> >> Role.optionNames == ["Admin", "Moderator", "User"] >> Role.allOptions == [ Admin, Moderator, User ] >> >> Now the 'allOptions' probably could work only when all type constructors >> have the exact same parameters, but I think that use case is not infrequent >> and having to define list of possible options manually is error-prone... >> >> The use case is not only for selects. You may for example need to show >> counts of various types of objects displayed, where the type is given by an >> enum, so iterating through the enum values makes sense. >> >> Just my $0.02. >> >> Martin >> >> On Wednesday, 26 October 2016 02:27:38 UTC+2, Ian Mackenzie wrote: >>> >>> I've been slowly working on a small library >>> <https://github.com/kintail/input-widget> to make working with the >>> basic input widgets like <select> more pleasant to work with - I'd be >>> interested to see what you think. The implementation >>> <https://github.com/kintail/input-widget/blob/master/src/Kintail/InputWidget.elm#L48> >>> handles >>> the mapping between selected index and strongly-typed values; check out >>> examples/ComboBox.elm >>> <https://github.com/kintail/input-widget/blob/master/examples/ComboBox.elm> >>> to >>> see a simple usage example. >>> >>> On Tuesday, 25 October 2016 23:45:26 UTC+11, James Hamilton wrote: >>>> >>>> Hello! >>>> >>>> I suppose this really only applies to instances of <option>, but there >>>> may be other examples. >>>> >>>> When using <option> with <select>, it's necessary to set a value on the >>>> <option> using <value> which accepts a String. However, I usually actually >>>> want to refer to a Type which I have to represent as a String and marshal >>>> it back to its correct type when updating the model. >>>> >>>> Is there a way of doing this using a type, and if not could it be done? >>>> I think it's a reasonable thing to expect to be able to do with an >>>> <option>, but then again I'm pretty new to this so please tell me if I'm >>>> asking for something complicated! >>>> >>>> -- 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.
