Why Do Some Extension Methods Not Work After Importing a C# Project?
When attempting to import C# Projects via the C# to DBLNET Conversion Tool (C# to Synergy DBL Conversion Tool):
The following Toy C# Program will generate a DBL-E-NFND () it appears to affect some, but not all Linq Extension Methods?
The toy program is straight forward and will remove all Nodes from the given XML File, this works without issue in C#.
C#
using System.Linq; using System.Xml.Linq; namespace LinqDoesNotWorkRemove { class Program { static void Main( string[] args ) { XDocument projFile = XDocument.Load("Sample.xml"); XElement[] nodes = projFile.Descendants().ToArray(); nodes.Remove(); } } }
DBLNET (Generated)
import System.Linq .array 0 import System.Xml.Linq namespace LinqDoesNotWorkRemove class Program public static method Main, void args, [#]string endparams proc data projFile, @XDocument, XDocument.Load("Sample.xml") data nodes, [#]@XElement, projFile.Descendants().ToArray() nodes.Remove() endmethod endclass main proc Program.Main(Environment.GetCommandLineArgs()) endmain endnamespace
What is the Technical Reason and where is the documentation that outlines this limitation?
C#
using System.Collections.Generic; using System.Linq; namespace LinqDoesNotWorkIEnumerableReturns { class Program { static void Main( string[] args ) { IEnumerable<int> result = GetFirst100OddNumbers(); IEnumerable<string> result2 = GetNumerics(); } internal static IEnumerable<int> GetFirst100OddNumbers() { IEnumerable<int> first100Numbers = Enumerable.Range(1, 100); // The file names at this point are relative; therefore we need to get the full path IEnumerable<int> result = first100Numbers.Where(number => number % 2 == 0); return result; } internal static IEnumerable<string> GetNumerics() { string[] inputs = new string[] { "A", "B", "C", "1", "2", "3" }; IEnumerable<string> result = inputs.Where(str => char.IsNumber(str.AsEnumerable().First())); return result; } internal static IEnumerable<string> GetNumericsToArray() { string[] inputs = new string[] { "A", "B", "C", "1", "2", "3" }; IEnumerable<string> result = inputs.Where(str => char.IsNumber(str.AsEnumerable().First())).ToArray(); return result; } } }
DBLNET (Generated)
import System.Collections.Generic .array 0 import System.Linq namespace LinqDoesNotWorkIEnumerableReturns class Program public static method Main, void args, [#]string endparams proc data result, @IEnumerable<int>, GetFirst100OddNumbers() data result2, @IEnumerable<string>, GetNumerics() endmethod internal static method GetFirst100OddNumbers, @IEnumerable<int> endparams proc data first100Numbers, @IEnumerable<int>, Enumerable.Range(1, 100) ;; The file names at this point are relative; therefore we need to get the full path data result, @IEnumerable<int>, first100Numbers.Where(lambda (number) { (number .mod. 2) == 0 }) mreturn result endmethod internal static method GetNumerics, @IEnumerable<string> endparams proc data inputs, [#]string, new string[#] {"A", "B", "C", "1", "2", "3"} data result, @IEnumerable<string>, inputs.Where(lambda (str) { char.IsNumber(str.AsEnumerable().First()) }) mreturn result endmethod internal static method GetNumericsToArray, @IEnumerable<string> endparams proc data inputs, [#]string, new string[#] {"A", "B", "C", "1", "2", "3"} data result, @IEnumerable<string>, inputs.Where(lambda (str) { char.IsNumber(str.AsEnumerable().First()) }).ToArray() mreturn result endmethod endclass main proc Program.Main(Environment.GetCommandLineArgs()) endmain endnamespace
The implementations are provided to arrays at run time, and as a result, the generic interfaces do not appear in the declaration syntax for the Array class.
So it seems the C# compiler is aware of the availability of IEnumerable<T> for arrays, but the DBL compiler is not. Adding an explicit cast will resolve the DBL error:
((IEnumerable<XElement>)nodes).Remove()
The TYPMISMCH error is interesting because the C# compiler resolves the Linq .ToArray() as a []string, but the DBL compiler resolves as a []char (per Intellisense). Splitting the code into two lines seems to work:
data result, @IEnumerable<string>, inputs.Where(lambda (str) { char.IsNumber(str.AsEnumerable().First()) })
result = result.ToArray()
You may want to pass along the TYPMISMCH example to Support as IMO it should resolve as a single line.
FYI, when I do use the C# to DBL Converter, my expectation is that it'll get me about 95% of what I need. There's so many nuances to how C# code can be written that I'm not sure it can ever get 100% converted code (but I'd sure be pleased if it did!). That's just my opinion, someone from the Development team may be able to provide a more accurate expectation of the converter.
> You may want to pass along the TYPMISMCH example to Support as IMO it should resolve as a single line.
Is the crux of the question, should we be filing these as bugs or what?
In a perfect world the C# to DBL Converter would be reliable enough for me to implement "Midnight Monkey Madness" in order to stress test the DBLNET Compiler to preemptively identify weaknesses/bugs in the compiler (PEVerify Errors) ideally before I find in in our production code base.
"Midnight Monkey Madness"
- Take Random C# Projects From GitHub
- Build them (make sure they build green)
- Shove them through the DBLNET Converter
- Check if the DBLNET Converter Fell Over <- If So Bug Report (DBLNET Converter)
- If the DBLNET Converter Worked; Compile, Check if the Compiler Fell Over <- If So Bug Report (DBLNET Compiler)
- If the Compile was successful check for PEVerify Errors <- If Error Bug Report (DBLNET Compiler/PEVerify)
It all depends on if we could rely on the DBLNET Converter to do its job...
** Midnight Monkey Madness is a Simpsons Quote (Treehouse of Horror XVIII):
Homer Simpson: I'll be going out late tonight. It's midnight monkey madness at the zoo.
Marge Simpson: Me too. I'll be overturning all the wheelbarrows in case it rains.
Homer Simpson: Well, enjoy your pointless activity.
Marge Simpson: Have fun at your preposterous event.
I'm going to defer to Development to define expectations on how robust the C# to DBL converter should be. I don't think the intent was ever to have it perform "Midnight Monkey Madness", specially given the variety of C# code and coding styles. I believe what you'll end up testing is "how well did the converter convert the code" vs. "there's an issue with a particular piece of DBL code".
As for me, I use it when I search for a specific problem and what I find are C# solutions; I'll use the converter when the code is too big to convert manually. I believe this is the intended use for the converter.
Again proves that there is no original content on the Internet.