Add static JsConsole class to expose the various console methods available in Javascript #396
Conversation
…lable in Javascript. Add polyfills for the (non-standard) methods found on console, to prevent errors (and provide some functionality) in browsers which don't support them.
…lable in Javascript. Add polyfills for the (non-standard) methods found on console, to prevent errors (and provide some functionality) in browsers which don't support them.
|
I placed this in a separate class just because it deviates significantly from the .NET Console API, though I can transplant the code the System.Console if you'd prefer. As for the polyfills, I can't seem to find any info on what your intended browser support/language level support for the Javascript produced by Saltarelle is and just took a nod from the fact that there are some Array#extras polyfills in mscorlib. I'm happy to remove the polyfills though if this library isn't specifically intended to produce code that can run unaided on older browsers. |
|
The policy is that mscorlib contains the polyfills required for mscorlib to work (but I am inclined to think that it should not depend on those methods of which I think there are 2). I don't think it hurts to have the methods in |
|
Yeah, the only issue with compatibility (when placing these methods on System.Console) would be the ability to compile a Saltarelle project as C# into a .dll, though there are already API extensions to some of the mscorlib classes which prevent such an action as far as I can tell. I'll get a commit pushed up that drops the polyfills and relocates the methods onto System.Console. |
Move JsConsole methods onto System.Console.
|
It does seem a shame to merge System.Console with a separate JsConsole. I'm not really sure what the benefit is, but the disadvantage is that you can't as easily target both .Net and JS without using #if blocks. Having System.Console standard methods write to the browser console is great, but where there are different methods for the browser console, if feels nicer to have these in a separate class, as they are not really part of CLR or BCL. IMHO |
Addresses #379.
Not 100% thrilled with the tests and would be willing to improve if you have any preference on a different testing strategy, but this is a difficult thing to confirm it works as expected through unit testing without potentially missing other issues as a result.