ToString and List.Add

Oct 14, 2011 at 2:05 PM

Hi fickerra, how's it going? btw thanks for implementing the default properties back in June :-)

I'm getting a compile error in haxe: "Int has no field toString."  How should I go about handling ToString for ints, floats and bools to avoid this error in haxe?


I'm also getting this one: "Array<..> has not field Add."

I assume this compile error is because of the limitations you describe under the "Lists, Stacks and Queues" heading.  I assume this is because cs2hx needs to know the type of the variable for the translations.xml.  Is it possible to avoid this and implement a List<T> type in haxe so the translation for Add to push doesnt need to be made?  If I was going to make a List type in the System folder, how would I go about removing the c# List to haxe Array translation in cs2hx? ie can I do this in translations.xml or do I need to modify the source?


Oct 14, 2011 at 8:51 PM

Hey! It's going well!

For the .ToString() problem on primitive types, I agree it's a problem right now - but the good news is there should be a fix coming.  First, the situation today:  If you're just doing string concatenation, you can just leave off the .ToString() and it will work on both sides.


"i = " + i.ToString()    becomes     "i = " + i


In cases where you're not doing string concatenation:  Unfortunately there's no way in haxe to add methods to the Int class like there is in C#.  I use the following work-around to make CS2HX think it's an extension method and re-format it appropriately.  First, define your own ToString function as an extension method:


#if !CS2HX
public static string ToStringExt(this object o)        {            return o.ToString();        }


Then you have to define this over on the haxe side:


package asdf;
public static inline function ToStringExt(o:Dynamic):String { return Std.string(o); }


And add an entry to your Translations.xml specified by command-line parameter to CS2HX:

<Method SourceObject="*" Match="ToStringExt" ExtensionNamespace="asdf" />

This works, but it's ugly, and requires manually changing ToString's to ToStringExt's.  


To the 2nd question:  Yes, it would be possible to implement a List type in haxe the same way that Dictionary was done.  In fact, I originally wrote CS2HX this way, but performance was terrible in Flash.  I noticed a huge speed-up when I converted it to use the Array type directly, but it has tradeoffs as you have noticed.

The main reason the current limitations exist is because CS2HX doesn't always know what type a variable is (basically whenever the type isn't written out in the code, like "var list = Foo()").  Therefore, sometimes it doesn't know to change "Add" to "push" when you do "list.Add".    

I'm not sure if you've been following Microsoft's project Roslyn, but this is a C# parser made by the C# team that exposes the code's AST in a way that I believe will have all of the type information.  They announced about a month ago that a CTP should be coming out in a month, so it should be any time now.  Once this comes out, I hope to re-write CS2HX using it and call it CS2HX 2.0.  I believe both of the issues you brought up here would be fixed with this, since it would be possible to know what type everything is.  If you would be interested in helping out with this, let me know.

Oct 15, 2011 at 2:58 AM

>>Yes, it would be possible to implement a List type in haxe...but performance was terrible in Flash

Did you originally implement the List class as a wrapper for haxe's Array?  I thought a simple wrapper would have little performance impact.

Roslyn sounds interesting.  Have you thought about instead reading from .net opcodes? (btw I'm not sure if you're parsing the code or parsing the IL).

Reading the opcodes would remove a lot of complexity introduced by the language - i.e wouldnt need to handle var keyword etc.

Oct 15, 2011 at 3:36 AM

CS2HX reads your C# code files, not the IL.  Converting at the IL level was actually the first thing I tried before I even started CS2HX.  It definitely helps in many cases, like knowing the types of ever variable, and it's post-overload resolution so you can know which overload a call is bound to.  It also helps in that you can use any .net language, not just C#.

While parsing at the IL level solves many of the challenges CS2HX faces, it has its own entirely different set of challenges.  For example, C#'s "switch" statement doesn't exist in IL - instead, the C# compiler compiles a switch down to a set of "goto" statements.  Many languages don't support goto (haxe, Actionscript, javascript), so implementing the IL is far more challenging.  Further, the output will look very different from your source code, which makes profiling and debugging difficult.  The bottom line is you lose a lot of the code's original context if you try to look only at its IL.

There's actually another project that attempts to do this though.  You can try it out and see if it's a better fit for you than CS2HX.  I tried to use JSC for my project but found its limitations far too limiting.  That's why I wrote CS2HX.

Oct 15, 2011 at 9:29 AM
Edited Oct 21, 2011 at 3:00 PM

Hi flickerra, ye the switch statements sound like a problem.  I think Roslyn would be the best way to go.

I've looked at a number of converters and found JSC incomplete in a number of areas.

Dec 9, 2012 at 11:29 PM
Edited Dec 9, 2012 at 11:31 PM

Hi flickera, I noticed a cs2hx2 folder with some Roslyn code in it.  Did you have any luck getting this to work?  Is this version usable in any way?


Dec 18, 2012 at 10:29 PM

Unfortunately I have not had time to finish it.  The code that's there currently was a work-in-progress and it's not currently usable.