So I was looking at this example code for DirectShow.Net, specifically their PlayCap example under the Capture folder example. You can download the samples here Its in C#. It does some interesting things with casting objects to interfaces. When I tried to recreate it faithfully in F#, the objects would not cast properly.
C#:
IVideoWindow videoWindow = null;
IMediaControl mediaControl = null;
IMediaEventEx mediaEventEx = null;
IGraphBuilder graphBuilder = null;
ICaptureGraphBuilder2 captureGraphBuilder = null;
and then later in GetInterfaces():
this.graphBuilder = (IGraphBuilder) new FilterGraph();
this.captureGraphBuilder = (ICaptureGraphBuilder2) new CaptureGraphBuilder2();
this.mediaControl = (IMediaControl) this.graphBuilder;
this.videoWindow = (IVideoWindow) this.graphBuilder;
this.mediaEventEx = (IMediaEventEx) this.graphBuilder;
So what I did for my code was this in F#:
let mutable videoWindow: IVideoWindow = null;
let mutable mediaControl: IMediaControl = null;
let mutable mediaEventEx: IMediaEventEx = null;
let mutable graphBuilder: IGraphBuilder = null;
let mutable captureGraphBuilder: ICaptureGraphBuilder2 = null;
And later in GetInterfaces():
graphBuilder <- new FilterGraph() :> IGraphBuilder
captureGraphBuilder <- new CaptureGraphBuilder2() :> ICaptureGraphBuilder2
mediaControl <- graphBuilder :> IMediaControl;
videoWindow <- graphBuilder :> IVideoWindow;
mediaEventEx <- graphBuilder :> IMediaEventEx;
It looked like a faithful recreation. Not even using functional style either. I was looking at the msdn on casting in F# to see if I was doing it correctly. It looks like I am, though they have 1 example and it is incredibly minimal in nature.
The problem is I get the error:
Type constraint mismatch. The type 'FilterGraph' is not compatible with the type 'IGraphBuilder'
I get a similar error for each one. I have tried downcasting too as well using :?>
I found myself encountering a similar issue, it turns out that in C# it's possible to add a GUID attribute to a COM interface and a COM implementation and the class would appear as a valid implementation of the interface. The F# type system is, however, stricter and doesn't allow this. You can assign them by using the unbox function as such
graphBuilder <- unbox (new FilterGraph())
captureGraphBuilder <- unbox (new CaptureGraphBuilder2())
Related
A couple days ago, I posted a question about deserialization with enums in F#.
The question is here: Deserialization in F# vs. C#
The answer pointed to some code written by Isaac Abraham, at: https://gist.github.com/isaacabraham/ba679f285bfd15d2f53e
However I am facing another problem:
If the object to deserialize to has an object of type 'enum option', the deserialization will fail, whereas it'll work if the type is just 'enum'.
A minimal example:
type TestType =
| A = 0
| B = 1
type TestObjectA =
{
test : TestType
}
type TestObjectB =
{
test : TestType option
}
let x = "{\"test\":\"A\"}"
let TestA = Deserialize<TestObjectA> x // will work
let TestB = Deserialize<TestObjectB> x // will fail
and the large deserialization code is at: https://pastebin.com/95JZLa6j
I put the whole code in a fiddle: https://dotnetfiddle.net/0Vc0Rh
but it can't be run from there since the F# version they support will not accept the 'object' keyword.
So, my question is: why can't I use the option type on an enum, but it works on other types? As a side note, since I'm quite new to F#, I'm not fully understanding Isaac's code, although I spent some time going through it and trying to troubleshoot it.
My understanding is that this line:
|> Seq.map (fun (value, propertyInfo) -> Convert.ChangeType(value, propertyInfo.PropertyType))
will try to convert the type to the right enum, but not to the enum option.
As a bonus question, is there a working solution that does full idiomatic deserialization with enums? (without going through null types)
open System.IO
type TestType =
| A = 0
| B = 1
type TestObjectB =
{
test : TestType option
}
let jsonSerializeToString obj =
use writer = new StringWriter()
let ser = new Newtonsoft.Json.JsonSerializer()
ser.Formatting <- Newtonsoft.Json.Formatting.Indented
ser.Serialize(writer, obj)
writer.ToString()
let jsonDeserializeFromString str =
Newtonsoft.Json.JsonConvert.DeserializeObject<TestObjectB>(str)
let Test obj =
let str = jsonSerializeToString obj
let obj' = jsonDeserializeFromString str
obj'
[<EntryPoint>]
let main argv =
{ test = Some TestType.B } |> Test |> ignore
{ test = None } |> Test |> ignore
0
Note: if you need to serialize a large collection of objects, then stream them to a file instead of an in-memory string to avoid an OutOfMemoryException. Like use writer = File.CreateText(filePath).
As a bonus question, is there a working solution that does full
idiomatic deserialization with enums?
I use the Microsoft.FsharpLu.Json package in production and find it works quite well for serializing and deserializing between "plain" javascript and idiomatic F#. Note Microsoft.FsharpLu.Json relies on Newtonsoft.Json under the hood.
Below is an example with your types and your test string, using Expecto for tests.
namespace FsharpLuJsonTest
open Newtonsoft.Json
open Microsoft.FSharpLu.Json
open Expecto
open Expecto.Flip
// Setup for FSharpLu.Json
type JsonSettings =
static member settings =
let s = JsonSerializerSettings(
NullValueHandling = NullValueHandling.Ignore,
MissingMemberHandling = MissingMemberHandling.Ignore)
s.Converters.Add(CompactUnionJsonConverter())
s
static member formatting = Formatting.None
type JsonSerializer = With<JsonSettings>
// Your example
type TestType =
| A = 0
| B = 1
type TestObjectA = { test : TestType }
type TestObjectB = { test : TestType option }
module Tests =
let x = """{"test":"A"}"""
[<Tests>]
let tests =
testList "Deserialization Tests" [
testCase "To TestObjectA" <| fun _ ->
JsonSerializer.deserialize x
|> Expect.equal "" { TestObjectA.test = TestType.A }
testCase "To TestObjectB" <| fun _ ->
JsonSerializer.deserialize x
|> Expect.equal "" { TestObjectB.test = Some TestType.A }
]
module Main =
[<EntryPoint>]
let main args =
runTestsInAssembly defaultConfig args
As you can see FsharpLu.Json supports Discriminated Unions and option types out of the box in the way you prefer. FsharpLu.Json is a less flexible solution than some others like Chiron (which allow for much more customisation) but I tend to prefer the opinionated approach of FsharpLu.Json.
I haven't used it personally, but the new FSharp.SystemText.Json library with the JsonUnionEncoding.ExternalTag setting should work roughly the same way FsharpLu.Json does. That library uses Microsoft's new System.Text.Json library under the hood rather than Newtonsoft.Json.
why in the world does the constructor for a dictionary in F# allow duplicate keys and just overwrites silently?
let ``you just got dict`` = dict [ "hello","goodbye";"hello","world"]
This is very counter-intuitive behavior.
You could shadow the built-in dict function with a version that behaves as you want. You could return the more fitting IReadOnlyDictionary interface while you're at it.
let dict source =
let d = Dictionary<'K, 'V>(HashIdentity.Structural)
source |> Seq.iter d.Add
{
new IReadOnlyDictionary<'K, 'V> with
member x.ContainsKey(key) = d.ContainsKey(key)
member x.TryGetValue(key, value) = d.TryGetValue(key, &value)
member x.Item with get key = d.[key]
member x.Keys = d.Keys :> _
member x.Values = d.Values :> _
interface IReadOnlyCollection<KeyValuePair<'K, 'V>> with
member x.Count = d.Count
interface IEnumerable<KeyValuePair<'K, 'V>> with
member x.GetEnumerator() = d.GetEnumerator() :> _
interface System.Collections.IEnumerable with
member x.GetEnumerator() = d.GetEnumerator() :> _
}
I can't explain the reason for this design - just as I can't explain why Dictionary<TKey, TValue> doesn't take a sequence of KeyValuePairs as input.
However, if you look at the implementation of dict, you'll see that it internally adds each element using the indexer, like this:
foreach (Tuple<TKey, TValue> tuple in keyValuePairs)
{
TValue local = tuple.Item2;
TKey local2 = tuple.Item1;
d[new RuntimeHelpers.StructBox<TKey>(local2)] = local;
}
where d is the Dictionary being created. The indexer silently updates the dictionary entry, so this explains the mechanics of it.
Not an entire answer, I admit, but perhaps a piece of the puzzle.
You aren't going to get a why unless some Microsoft engineer explains it to you why they chose to do it that way. Regardless, it is what it is and works just as the documentation says it should:
https://msdn.microsoft.com/en-us/library/k7z0zy8k(v=vs.110).aspx
Remarks
You can also use the Item property to add new elements by setting the value
of a key that does not exist in the Dictionary<TKey, TValue>; for example,
myCollection[myKey] = myValue (in Visual Basic, myCollection(myKey) =
myValue). However, if the specified key already exists in the
Dictionary<TKey, TValue>, setting the Item property overwrites the old
value. In contrast, the Add method throws an exception if a value with the
specified key already exists.
I have a FileReader class whose job is to read and process text files using a StreamReader. To facilitate unit testing, I'd like to provide a type parameter to this class so that I can swap the StreamReader for a FakeReader that doesn't actually interact with the file system (and maybe throws exceptions such as OutOfMemory, so I can test the error handling in FileReader).
Ideally, I'd like to define FileReader something like this (trivialized for clarity):
type FileReader<'Reader> =
member this.Read file =
use sr = new 'Reader(file)
while not sr.EndOfStream do
printfn "%s" <| sr.ReadLine()
and simply define FakeReader to have a constructor that takes the file name, the EndOfStream property getter, the ReadLine() method, and the (empty) Dispose() method. However, F# has several complaints about this type definition, including "Calls to object constructors on type parameters cannot be given arguments." Since StreamReader has no default constructor, this approach seems like a no-go.
So far the only way I've gotten this to work is to inherit FakeReader from StreamReader:
type FakeReader() =
inherit StreamReader("") with
override this.ReadLine() = "go away"
member this.EndOfStream = false
member this.Dispose() = ()
and use a factory method that returns either a new FakeReader or a new StreamReader as appropriate.
type ReaderType = Fake | SR
let readerFactory (file : string, readerType) =
match readerType with
| Fake -> new FakeReader() :> StreamReader
| SR -> new StreamReader(file)
type FileReader(readertype) =
member this.Read file =
use sr = readerFactory(file, readertype)
while not sr.EndOfStream do
printfn "%s" <| sr.ReadLine()
This seems a lot less elegant. Is there a way to do this with a type parameter? Thanks to all.
Using a function that creates a reader object (as suggested by MizardX) is the direct answer to your question. However, I'd maybe consider using a different abstraction than TextReader). As Ankur mentioned in a comment, you could use a more functional approach.
If you're just reading lines of text from the input using TextReader, you could use a seq<string> type instead. The FileReader type may actually be just a function taking seq<string> (although that may be oversimplification... it depends).
This makes it more "functional" - in functional programming, you're often transforming data structures using functions, which is exactly what this example does:
open System.IO
/// Creates a reader that reads data from a file
let readFile (file:string) = seq {
use rdr = new StreamReader(file)
let line = ref ""
while (line := rdr.ReadLine(); !line <> null) do
yield !line }
/// Your function that processes the input (provided as a sequence)
let processInput input =
for s in input do
printfn "%s" s
readFile "input.txt" |> processInput
To test the processInput function, you could then create a new seq<string> value. This is significantly easier than implementing a new TextReader class:
let testInput = seq {
yield "First line"
yield "Second line"
raise <| new System.OutOfMemoryException() }
testInput |> processInput
You could pass in a function that constructs and returns an object of your desired type.
type FileReader(f : string -> TextReader) =
member this.Read file =
use sr = f file
while sr.Peek() <> -1 do
printfn "%s" <| sr.ReadLine()
type FakeReader() =
inherit StringReader("")
override this.ReadLine() = "go away"
override this.Peek() = 0
let reader1 = new FileReader(fun fn -> new StreamReader(fn) :> _)
let reader2 = new FileReader(fun fn -> new FakeReader() :> _)
Cast was necessary because I dropped the generic type-argument, but the actual type can be inferred.
For a project I am working on I need a global variable(technically I don't, I could build it and then pass it to every single function call, and let every single function call know about it, but that seems just as hacky, less readable and more work.)
The global variables are look up tables(endgame, opening book and transpositions/cache) for a game.
The fact that some of the code may lose some of it's indempotent behavior is actually the point(speedups) in short, yes I know global mutable state is bad, it's really worth it in this case(10x+ performance improvement)
So here's the question, "build a singleton or use a static value in a static class with combinators"
They are effectively identical but I am curious what people have done before on this sort of problem
Or alternatively, should I be passing the thing around to everyone(or at least a reference to it anyways),is that really the best answer?
Here is a solution similar to the one posted by #Yin Zhu's, but using abstract types to specify a usage interface for the mutable value, a local definition to encapsulate it and object literals to provide an implementation (this is taken from Expert F#--which is co-authored by Don Syme):
type IPeekPoke =
abstract member Peek: unit -> int
abstract member Poke: int -> unit
let makeCounter initialState =
let state = ref initialState
{ new IPeekPoke with
member x.Poke(n) = state := !state + n
member x.Peek() = !state }
You can also do it with static fields, like this:
type Common() =
static let mutable queue : CloudQueue = null
static let mutable storageAccount : CloudStorageAccount = null
static member Queue
with get() = queue
and set v = queue <- v
static member StorageAccount
with get() = storageAccount
and set v = storageAccount <- v
In another module, just:
open Common
Common.Queue <- xxxx
here is the convention used in F# PowerPack Matrix library (\src\FSharp.PowerPackmath\associations.fs):
// put global variable in a special module
module GlobalAssociations =
// global variable ht
let ht =
let ht = new System.Collections.Generic.Dictionary<Type,obj>()
let optab =
[ typeof<float>, (Some(FloatNumerics :> INumeric<float>) :> obj);
typeof<int32>, (Some(Int32Numerics :> INumeric<int32>) :> obj);
...
typeof<bignum>, (Some(BigRationalNumerics :> INumeric<bignum>) :> obj); ]
List.iter (fun (ty,ops) -> ht.Add(ty,ops)) optab;
ht
// method to update ht
let Put (ty: System.Type, d : obj) =
// lock it before changing
lock ht (fun () ->
if ht.ContainsKey(ty) then invalidArg "ty" ("the type "+ty.Name+" already has a registered numeric association");
ht.Add(ty, d))
type SQLConn =
val mutable private connection : string option
member this.Connection
with get() : string = this.connection.Value
and set(v) = this.connection <- Some v
new (connection : string) = {connection = Some connection;}
new() = SQLConn #"Data Source=D:\Projects\AL\Service\ncFlow\dbase\dbflow.db3; Version=3;Password=432432434324"
I want to use "let x = 5+5" there or something like that, so how can I use private functions in my type (class) (record) , I know that I can use them if I do SQLConn() , but then I can't use val, I want to use both : val and let ...
thank you
As Tim explains, you can only use local let bindings with the implicit constructor syntax. I would definitely follow this approach as it makes F# code more readable.
Do you have any particular reason why you also want to use val in your code? You can still use them with the implicit constructor syntax, but they have to be mutable and initialized using mutation:
type SQLConn(connection:string) as x =
let mutable connection = connection
// Declare field using 'val' declaration (has to be mutable)
[<DefaultValue>]
val mutable a : int
// Initialize the value imperatively in constructor
do x.a <- 10
member this.Connection
with get() = connection and set(v) = connection <- v
new() = SQLConn #"Data Source=.."
As far as I can tell val is only needed to create fields that are not private (which may be required by some code-gen based tools like ASP.NET, but is otherwise not really useful).
The error message explains the problem:
error FS0963: 'let' and 'do' bindings are not permitted in class definitions unless an implicit construction sequence is used. You can use an implicit construction sequence by modifying the type declaration to include arguments, e.g. 'type X(args) = ...'.
The error message is suggesting that you declare your class as type SQLConn(connection) =. If you do this, you probably ought to remove the member this.Connection property, since you'll no longer have a mutable field.
A more likely workaround would be to declare x as val x : int, then put the x = 5 + 5; initializer inside your constructor.
What about the following?
type SQLConn(conn:string) =
// could put some other let bindings here...
// ex: 'let y = 5 + 5' or whatever
let mutable conn = conn
new() = SQLConn(#"some default string")
member __.Connection
with get () = conn and set v = conn <- v