Implicit Converters

I already spoke a bit about converting types.

Since in FlareTic all the "dataflow patch types" use some form of generic holder for pins, link is done simply as:

Check if input type is assignable from output type, if yes allow link.
Now this creates some issues as for example float is not assignable to bool.

So I don't want to create AsBool (Float) , AsFloat(Bool) and so on for all types, that makes a patch bloated for nothing, I need another solution.

Enters converters

Code Snippet

33. public interface ITypeConverterFactory
34. {
35.     bool CanConvert(Type from, Type to);
36.     ITypeConverter CreateConverter();
37. }
38.  
39. public interface ITypeConverter
40. {
41.     object Convert(object from);
42.     bool Warning { get; }
43.     string WarnMessage { get; }
44. }

The first interface allows to check if we can convert types, and when we connect creates the converter that does the job.

Now when we check for connection, we have a list of factories, so if we find a converter, we can link :)

For raw .NET primitive types, you have to build by yourself, so to speed this up, few generic builders:

Code Snippet

11. public class FuncConverter<TFrom, TTo> : ITypeConverter
12. {
13.     private readonly Func<TFrom, TTo> convertFunc;
14.     private readonly bool warning;
15.     private readonly string message;
16.  
17.     public FuncConverter(Func<TFrom, TTo> func, bool warning, string message)
18.     {
19.         this.convertFunc = func;
20.         this.warning = warning;
21.         this.message = message;
22.     }
23.  
24.     public object Convert(object from)
25.     {
26.         return this.convertFunc((TFrom)from);
27.     }
28.  
29.     public bool Warning
30.     {
31.         get { return this.warning; }
32.     }
33.  
34.     public string WarnMessage
35.     {
36.         get { return this.message; }
37.     }
38. }

And the factory :

Code Snippet

40. public abstract class FuncConverterFactory<TFrom, TTo> : ITypeConverterFactory
41. {
42.     private readonly Func<TFrom, TTo> convertFunc;
43.     private readonly bool warn;
44.     private readonly string msg;
45.  
46.     public FuncConverterFactory(Func<TFrom, TTo> func, bool warning = false, string message = "")
47.     {
48.         this.convertFunc = func;
49.         this.warn = warning;
50.         this.msg = message;
51.     }
52.  
53.     public bool CanConvert(Type from, Type to)
54.     {
55.         return from == typeof(TFrom) && to == typeof(TTo);
56.     }
57.  
58.     public ITypeConverter CreateConverter()
59.     {
60.         return new FuncConverter<TFrom, TTo>(this.convertFunc, this.warn, this.msg);
61.     }
62. }

Next bit of boilerplate, could have done several ways, but you only do it once ;)

Code Snippet

64. public class IntToFloatConverter : FuncConverterFactory<int, float>
65. {
66.     public IntToFloatConverter() : base(i => i) { }
67. }
68.  
69. public class FloatToIntConverter : FuncConverterFactory<float, int>
70. {
71.     public FloatToIntConverter() : base(f => (int)f, true, "Conversion from float to int is explicit, some data can be lost" ) { }
72. }

You can notice that explicit casting also induce a message, so we can warn user in some cases.

Now for all other types, we go reflect implicit/explicit table for other types:

Code Snippet

131. public class ImplicitReflectionConverterFactory : ITypeConverterFactory
132. {
133.     public bool CanConvert(Type from, Type to)
134.     {
135.         var f = from.GetMethods().Where(
136.             m => m.Name == "op_Implicit"
137.             && m.ReturnType == to
138.             && m.GetParameters().Count() == 1
139.             && m.GetParameters()[0].ParameterType == from).FirstOrDefault() != null;
140.  
141.         if (f) { return true; }
142.  
143.         f = to.GetMethods().Where(
144.             m => m.Name == "op_Implicit"
145.             && m.ReturnType == to
146.             && m.GetParameters().Count() == 1
147.             && m.GetParameters()[0].ParameterType == from).FirstOrDefault() != null;
148.  
149.         return f;
150.     }
151.  
152.     public ITypeConverter CreateConverter()
153.     {
154.         return new ImplicitReflectionConverter();
155.     }
156. }

Now let's go a bit forward, why not also being able to auto convert opencv image to dx11 texture, that's why you use a converter factory, since now converter will also hold a resource, so we need one instance per link.

Converter code is just boilerplate, create texture for the same format as opencv image, and copy content in gpu when possible.

Here we go, of course user interface must reflect that we are using a converter, so blue mean converter, yellow means converter with warning.

Now opencv image can be directly linked to any node that wants a texture, and you can notice sharpdx types can be auto translated (Color4 has a Vector3 explicit operator, so it's automatically scanned by the reflector).

I love clean patches ;)

Now one common issue, we might want some form of control over the conversion, for example, float to string, we'd like to specify a format. So let's push the concept forward and make our link configurable via inspector.

Easy then, let's add a small additional interface:

Code Snippet

46. public interface IConfigurableTypeConverter : ITypeConverter
47. {
48.     IEnumerable<IParameter> Parameters { get; }
49. }

And here we go:

Code Snippet

13. public class StringFormatConverter : IConfigurableTypeConverter
14. {
15.     private StringParameter format;
16.  
17.     public StringFormatConverter()
18.     {
19.         this.format = new StringParameter(new StringParameterConverter());
20.         this.format.Value = "f";
21.         this.format.Name = "Format";
22.     }
23.  
24.     public object Convert(object from)
25.     {          
26.        return String.Format("{0:" + format.Value + "}", from);
27.     }
28.  
29.     public bool Warning
30.     {
31.         get { return false; }
32.     }
33.  
34.     public string WarnMessage
35.     {
36.         get { return ""; }
37.     }
38.  
39.     public IEnumerable<IParameter> Parameters
40.     {
41.         get
42.         {
43.             yield return this.format;
44.         }
45.     }
46. }

Now when we select a link in the editor, if it implements this interface we can manage properties, as per the screenshot:

So far it's great, using the reflection from c# helped to speed up the process a lot.

On next stage, we have the obvious question/problem, what happens if we have multiple converters that allow similar types?

Here we have several choices:

• Take the first one
• Show a selector when we complete link
• Have the selector in the inspector instead

I haven't made a choice, but take first one + selector is the most sensible option for now.