Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace obj with discriminated unions for better type safety and type discoverability #139

Closed
TimLariviere opened this issue Jul 24, 2018 · 4 comments
Labels
s/needs infos The issue needs to be completed

Comments

@TimLariviere
Copy link
Member

Some properties are bound like obj in the json file to allow implicit conversion just like we would do in XAML.
E.g. Image.Source can be set as a string or as an ImageSource.
Or GridRowDefinition can be either "*" or GridLength.Star
Same with View.Margin

But when using such types, IntelliSense only shows that the property is obj.
Developers don't know about the implicit conversions (if they didn't check the samples) and must look into the documentation of Xamarin.Forms to know what type exactly is allowed.

Wouldn't changing those obj to discriminated unions be better?
It would make typing explicit to developers, while allowing the compiler to check if there's nothing funny going on.
And cherry on top, converters would output warnings if we're missing a case (which is not the case currently with type matching)

What do you think?

@dsyme
Copy link
Collaborator

dsyme commented Jul 24, 2018

I think F# should have type-tagged union types (string|ImageSource) (erased to obj). I am hoping we can add those in F# 5.0, partly driven by exactly this question

@dsyme dsyme added the s/needs infos The issue needs to be completed label Jul 24, 2018
@TimLariviere
Copy link
Member Author

That would be great!

Is it something that will come in the foreseeable future (e.g. ~6 months)?
Or should we do something in the meantime and replace later once out?

@dsyme
Copy link
Collaborator

dsyme commented Jul 26, 2018

I think it will take longer,. maybe a year to see through to all relevant tooling. I feel using "obj" is likely ok for now, as people nearly always do view elements via cut-and-paste snippets, but I know it's not ideal.

@TimLariviere
Copy link
Member Author

Closing due to #341

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
s/needs infos The issue needs to be completed
Projects
None yet
Development

No branches or pull requests

2 participants