> When developing a web app in Nim, you shouldn't look at the generated
> JavaScript, just like you don't look at the generated C when developing a
> native program in Nim.
Disagree. If you are using JS, there are high chance that you going to need
some JS libraries. And the simple the integrat
Very good point. Didn't think of it.
So, I guess - for good reasons - it is what it is.
And then you could also have `proc test(n: int)`, since Nim supports name-based
overloading…
Well the issue with always outputting the proper name is in Nim we have types,
JS doesnt so the following code is valid in Nim.
proc test(a, b: int) = discard
proc test(a, b: float) = discard
Run
both output:
function test(a,b){}
Run
> This could be default way for generating var names, at least those which are
> not derived
I think, at least it would be great to have an _option_ that all names are
generated as is without the trailing number.
Because it's pretty painful to add `{.exportc.}` to many declarations if you
want
It doesn't matter for debugging as you have Nim stack traces and that compiler
can generate source maps for the JS backend.
> When developing a web app in Nim, you shouldn't look at the generated
> JavaScript, just like you don't > look at the generated C when developing a
> native program in Nim.
For simple todo app, sure.
> and other people in the organisation are no Nim fans - yet. ;-)
I can assure you they will be even less fans of the generated JS output from
Nim...
When developing a web app in Nim, you shouldn't look at the generated
JavaScript, just like you don't look at the generated C when developing a
native program in Nim.
This could be default way for generating var names, at least those which are
not derived. There's no need for names like `var answer_4576375436745 = 42` at
all
Then i would write it in JavaScript. (Or get the others to also write nim :) ).
I think changeing the generated js code will get your team in a lot of troubles
later on, and you cannot compile from nim any more, since you would lose the
changes.
You can export variables the same way as functions. JavaScript doesn't have
custom types, so exporting a type doesn't really make sense.
So, the self-defined function names look good now - Is any way to get my
variables and types without the trailing numbers in the JS output?
I expected a comment like this... :-)
The whole situation is not ideal, of course, but other people (very
occasionally) will need to maintain the code after I hand over the project -
and other people in the organisation are no Nim fans - yet. ;-)
The idea with `push` and `pop` is great; this way I can make all self-defined
function names easily very readable.
If you want an even worse idea: make Nim compile to TypeScript, so that type
information is not lost :P
> I checked how the generated JavaScript looks, because at some stage we might
> need to maintain the JavaScript output without the Nim source.
Why would you ever do that... It's one of the worst ideas I've ever come
across. For a start, the Nim source has valuable type information, the
generat
Or just `{.exportc.}` to use the proc name. `{.push exportc.}` might help if
you want to do it for multiple procs in a row
It's mainly just for JS interop but you can do `exportC: "Name"` on the
procedure to give it a nice JS name.
For my current project I use the JS backend. I checked how the generated
JavaScript looks, because at some stage we might need to maintain the
JaavScript output without the Nim source.
So it is good that the JavaScript code is fairly readable, however all function
names (plus other identifiers
20 matches
Mail list logo
