3 ms·

I'm not sure I follow. The struct type wouldn't need to exist in the resulting code. A struct instance could just be a normal associative array, with each field

by 3np 5y ago

I'm not sure I follow. The struct type wouldn't need to exist in the resulting code. A struct instance could just be a normal associative array, with each field mapped recursively. (Or is there some gotcha with C# structs I am not aware of?) Any type information required at runtime can be encoded into a string. Javascript is Turing-complete and therefore, fundamentally, any valid C# program has at least one JS representation. (I'm not saying any of this will be efficient, a great idea or experience; just that it's possible)

tluyben2 5y ago
It is also not as elaborate as your parent is trying to say. It's less straight forward than TS->JS (because they are intentionally super/sub languages and the same runtime) but it's not the 'magic' that is indicated. That's why there have been many transpilation projects (which were quite perfect and solid, just missing libraries). Without the tooling and support they are useless though (and died).
ameliaquining 5y ago
The gotcha with C# structs is that they're passed by value. If I pass a struct, and then the callee mutates one of its fields, this isn't reflected in the caller. JavaScript values other than primitives do not work this way. If your codebase is entirely C# and you're just compiling it to JS so that it can run in browsers, then the compiler can fix this by inserting copies where needed. (The Turing-completeness of JavaScript implies that something like this must be possible.) However, if you want to be able to freely call back and forth between C# code and JavaScript code that doesn't know about this calling convention, while maintaining the full semantics of both languages, then you are going to run into problems. That's what I'm claiming is hard. There's no conceptual barrier to reflection; the problem is just that the required type information might be a lot of bytes, and it might be hard to tell for sure whether it's actually used at runtime. You might also have to ship a lot of support code that emulates enough of the CLR to make these operations work. So there'd be a strong temptation to just not support these features, which then would cause dependencies to break unpredictably.
- 3np 5y ago
  > However, if you want to be able to freely call back and forth between C# code and JavaScript code that doesn't know about this calling convention, while maintaining the full semantics of both languages, then you are going to run into problems. Ah. You’re talking about something different here, hence the confusion. Here’s where I came in: > I would like for c# to compile to TS or JS with the same support as ts to js. > I don't think this can work.
  - ameliaquining 5y ago
    Yeah, I took "same support as TS to JS" to mean "seamless interop".

by 3np 5y ago

tluyben2 5y ago

It is also not as elaborate as your parent is trying to say. It's less straight forward than TS->JS (because they are intentionally super/sub languages and the same runtime) but it's not the 'magic' that is indicated. That's why there have been many transpilation projects (which were quite perfect and solid, just missing libraries). Without the tooling and support they are useless though (and died).

ameliaquining 5y ago

The gotcha with C# structs is that they're passed by value. If I pass a struct, and then the callee mutates one of its fields, this isn't reflected in the caller. JavaScript values other than primitives do not work this way. If your codebase is entirely C# and you're just compiling it to JS so that it can run in browsers, then the compiler can fix this by inserting copies where needed. (The Turing-completeness of JavaScript implies that something like this must be possible.) However, if you want to be able to freely call back and forth between C# code and JavaScript code that doesn't know about this calling convention, while maintaining the full semantics of both languages, then you are going to run into problems. That's what I'm claiming is hard. There's no conceptual barrier to reflection; the problem is just that the required type information might be a lot of bytes, and it might be hard to tell for sure whether it's actually used at runtime. You might also have to ship a lot of support code that emulates enough of the CLR to make these operations work. So there'd be a strong temptation to just not support these features, which then would cause dependencies to break unpredictably.

3np 5y ago
> However, if you want to be able to freely call back and forth between C# code and JavaScript code that doesn't know about this calling convention, while maintaining the full semantics of both languages, then you are going to run into problems. Ah. You’re talking about something different here, hence the confusion. Here’s where I came in: > I would like for c# to compile to TS or JS with the same support as ts to js. > I don't think this can work.
- ameliaquining 5y ago
  Yeah, I took "same support as TS to JS" to mean "seamless interop".