Discriminated Union exposed by FountainDocument.Blocks is not C# friendly

[BenBtg]

I'm having some trouble trying to use the FountainBlockElements exposed by the FountainDocument.
As C# dev with no F# experience attempting to use the API. I'm struggling to deference the weak types exposed in my Xamarin.Forms app.
I don't understand the exactly what the problem is but the types returned all derive from FountainBlockElement have item1, item2, etc.. instead of strongly typed members.
According to my research discriminated unions should not be exposed to C# as per the F# guidlines.
For more info
https://stackoverflow.com/questions/23843142/f-discriminated-union-usage-from-c-sharp
I will see if I can work out the solution and provide a PR if possible.

[gabor-nemeth]

Probably we should not have exposed the Blocks property of FountainDocument at all, but e.g. it is used by the unit tests written in F#.
As far as I remember, the API meant to be exposed to .NET clients is about only loading text into FountainDocument and formatting as HTML. All other exposed types are basically side effects, and can only be accessed through F# clients effectively - although there could be exceptions 😄 It requires some work to make the whole library .NET friendly.
The properties of discriminated unions don't have names, that's why you see Item1, Item2, ... Only in F# you can assign names to them during pattern matching.

[BenBtg]

@gabor-nemeth Thanks for the clarification. I'm reading up on F# to try to understand exactly what would be required to get what I'm looking for.
I'm currently successfully using the Blocks property in a Forms app using DataTemplates in XAML to resolve the "dynamic properties" as they don't need to be strongly typed and get resolved at run time. However I realise that this is a hack an so would prefer a more .NET friendly solution if I could find one.

Current options seem to be
1: Update this F# lib to expose strongly typed classes for each BlockType.
2: Write my own C# Fountain parser.

I'd definitly prefer option 1 even if it requires learning some F#!

[gabor-nemeth]

@BenBtg 👍 It's not that much of work to achieve option 1. You can add helper functions to FountainBlockElement like AsAction(), AsCharacter(), AsDialogue(), etc. then return the actual type from those. Of course if you'd like friendly named properties, you should add new type for each case like ActionBlock, CharacterBlock, DialogueBlock, etc. This way you can preserve the functional F# code and create a wrapper for other .NET languages.

[BenBtg]

I will work towards option 1 then and plan to send a PR as soon as I have something.
Thanks for your guidance.