$jsilcore vs JSIL

[iskiselev]

There is a lot of helper functions in JSIL.Bootstrap.js, some of them are attached to $jsilcore, others to JSIL?

What is a border condition, whether it should be attached? Do I correct, that "public" functions are attached to JSIL and private to $jsilcore? Is then it correct, that some of $jsilcore attached functions are used in file other then where they are defined?

[kg]

It's been ages, but if memory serves:

JSIL is just a public blob of functions. It's global. Private functions should be JSIL.$xxx instead of JSIL.xxx but I was never consistent about that.

Essentially, $jsilcore is an underlay for all the BCL assemblies. All the core system assemblies like mscorlib and System use it as a prototype, which makes it possible to find System.String and such even if no BCL stubs are loaded. The automated tests rely on this. It's a gross hack. It's not public or private by nature, though.

I was never consistent about what I tucked into $jsilcore vs JSIL. I might have had a system in mind but I've forgotten it. It would make sense to store internal state in $jsilcore.foo but there's nothing intrinsically superior about that, other than making it so that it doesn't show up when you type JSIL. in Chrome Developer Tools.

[iskiselev]

Currently JSIL have a lot of helper function (I'm talking about functions that are defined in same files, where BCL classes are implemented), mostly attached to $jsilcore and JSIL, but some of them attached to root object. Such functions could be mostly grouped into 2 categories: that define part of class implementation (such as $jsilcore.$ListExternals) and all others - that do some calculation/work (JSIL.Dispose, JSIL.EnumerableToArray and so on).

I'm thinking about creating some helper types for functions of second category and moving them as "Raw" static method of this types. After it scope of JSIL JS public API will have better shape/will be more manageable.

@kg, what do you think about it? Will be there any problems with it that I don't see now or performance hit from it?

[iskiselev]

Other change that we may do - surround BCL classes defining JS files with self-invoke function and do not attach helper functions that are not used outside defining file to $jsilcore or JSIL and change it to scope variable.

[kg]

That sounds fine. Moving the methods onto static classes shouldn't be a performance problem; if it is we can just fix it.

Categorizing the methods is a good idea and something I should have done sooner. You can see that I've done a little of this with newer things like Unsafe and PInvoke but it's not universal