ECMAScript 2023 Spec for JavaScript Includes New Methods for Arrays (infoworld.com) 34
Four new capabilities are planned for the JavaScript specification's next update, reports InfoWorld. Based on a list of finished proposals, InfoWorld expects the following in ECMAScript 2023:
- Array find from last, a proposal for .findlast() and .findLastIndex() methods on array and typed array...
- Permitting symbols as keys in WeakMap keys, a proposal that extends the WeakMap API to allow the use of unique symbols as keys. Currently, WeakMaps are limited to allow only objects as keys.
- Change array by copy, a proposal that provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change.
- Hashbang grammar, a proposal to match the de facto usage in some CLI JS hosts that allow for Shebangs/Hashbang. These hosts strip the hashbang to generate valid JS source texts before passing to JS engines. This plan would move the stripping to engines and unify and standardize how that is done.
- Permitting symbols as keys in WeakMap keys, a proposal that extends the WeakMap API to allow the use of unique symbols as keys. Currently, WeakMaps are limited to allow only objects as keys.
- Change array by copy, a proposal that provides additional methods on Array.prototype and TypedArray.prototype to enable changes on the array by returning a new copy of it with the change.
- Hashbang grammar, a proposal to match the de facto usage in some CLI JS hosts that allow for Shebangs/Hashbang. These hosts strip the hashbang to generate valid JS source texts before passing to JS engines. This plan would move the stripping to engines and unify and standardize how that is done.
Re:This is news? (Score:5, Insightful)
Re: (Score:2, Troll)
I, for one, look forward to everyone's grandparents switching to the latest web browser version to make use of these new features.
Re:This is news? (Score:4, Interesting)
Re: (Score:2)
>...but when it comes to anything that requires user input,
Javascript doesn't only run inside a web browser. NodeJS is quite popular on the back-end and not always used for "user input".
Re: (Score:2)
This post is merely an opportunity for all the JavaScript haters to dump their rage against the inferiority of the language.
Can someone start the demonstration by lecturing on how the use of third-party package libraries will lead to the downfall of society?
The hashbang part is "archived" on github (Score:3)
What is the point on archiving it? Can not even open an issue.
The hashbang syntax is wrong or missleading:
#!/usr/bin/env node
Between the bang and the slash should be a space, or at least a space allowed.
Historically scripts starting with a shebang, would all start like this:
#!_/
Where the _ is in fact a space character. By that every "text" starting with #! would have the same 4 bytes magic file type number.
Re: (Score:1)
Nope. That's a totally bogus assumption to make.
"#! interp", "#! ./interp" (and their variants with multiple spaces after the "!") are all perfectly valid shebangs that will be accepted by any real life unix system and will use the "interp" program from the current dir as the interpreter.
Re: (Score:2)
It is not the unix system.
It is the interpreter that fucks up, see the wren cli. They treat " " wrong.
And 'Im pretty sure that java script implementation does it too.
Seriously: what is so complicated to grasp in the problem I pointed out?
"#! interp", "#! ./interp" (and their variants with multiple spaces after the "!")
Yes they are. And in wren it does not work, and I'm sure in this new ecma script sample implementation: it does not work. HENCE: I pointed it out!!
Re: (Score:1)
> And 'Im pretty sure that java script implementation does it too.
> And in wren it does not work, and I'm sure in this new ecma script sample implementation: it does not work.
What makes you so sure? The grammar link I gave you below shows that it should just skip the first line if it starts with #!. It doesn't care if it's followed by a space, a slash or whatever. And the node and spidermonkey implementations already do the same, as you could've easily checked if you bothered to test.
> HENCE: I poi
Re: (Score:1)
And it's not clear what your objection to that proprosal is, since the grammar [tc39.es] already accepts any character after the "#!".
As, to that "#!/usr/bin/env my_ass" example, the real problem is with the pointless and dangerous use of "/usr/bin/env", which was unfortunately spread like wildfire by all those python & bash cargocult cretins, so much that naive people have come to assume that that's the "idiomatic" way to write a script on Linux.
Re: (Score:2)
And it's not clear what your objection to that proprosal is, since the grammar already accepts any character after the "#!".
Sure.
Come back when you grasp the problem.
Re: (Score:2)
Between the bang and the slash should be a space, or at least a space allowed.
I couldn't find an RFC related to this, but I tested it in "bash", "dash", and "sh", with and without space, and they all showed the right interpretation via "ps -ef | grep $$ | grep -v grep" in the script. Now, when I replace the shebang line with "#!/bin/lsllll", with or without space, I got a bad interpreter message.
Re: (Score:2)
Are you sure you have /bin/lsllll on your system?
Re: (Score:2)
Re:The hashbang part is "archived" on github (Score:4, Informative)
Hate to break it to you, but files beginning with "#!" are actually executed by the KERNEL and not the shell (though in some OSes, the kernel may call the shell to parse the shebang line).
All that happens is you're calling exec() on an executable file. The shell doesn't inspect the file first to see if it's a shell script. It goes into the kernel.
The kernel executable loader then examines the file to see if it's something it can execute - is it ELF? Mach-O? a.out? Or finally, a file with a shebang?
Now, after that, some kernels will perform the equivalent of a system() C library call with the string after the shebang with the file path appended. In Linux, the kernel will actually parse the string out and restart the exec() call with the interpreter (the first non-whitespace string after "#!" terminated with whitespace) as the target, and the rest of the parameters as parsed out.
See for yourself - it's in fs/binfmt_script.c in the kernel tree.
https://git.kernel.org/pub/scm... [kernel.org]
Bad interpreter is the return value of exec() it it couldn't load the interpreter, but that's produced by the kernel, not the shell in Linux.
Re: (Score:2)
Re: (Score:3, Informative)
No, there no "return value of exec()" whose description is "Bad interpreter". There's no errno value corresponding to that message. If you guys would stop spouting out whatever crap you're assuming and do some minimal fact-check, that would be great.
That "bad interpreter" WAS a message generated by bash, after `execve()` has failed, bash has ispected the content of the
Re: (Score:2)
Of course the shell inspects the first line.
The kernel has absolutely nothing to do with it.
That e.g. is why "#! /" versus "#!/b" is a difference. Hint: the shell actually even looks into the $PATH :P
Neither the linux Kernel or any other unix kernel knows about $PATH.
The source code you linked seems to be part of a linux kernal module, though. No idea what it is supposed to do.
On my mac there are interpreters that do not start if you have space between ! and / - so clearly not a thing happening in the kerne
Re: (Score:2)
What is the point on archiving it?
i'd rather ask what its the point of proposing this to the ecmascript standard. why in heaven should a language engine deal with shell script syntax it has nothing to do with. this is just stupid, i don't even care that it isn't a proper standard, it's simply not the interpreter's business. kids these days ...
Re: (Score:2)
It is not shell script syntax.
It is syntax to start any interpreter from a text/script file and let that interpreter interpret the rest of the script.
We do that since 70+ years with any language that can be "interpreted on the fly".
Re: (Score:2)
it still isn't a language's interpreter's responsibility. one fundamental tenet of software design is that each component deals with its own domain and nothing else.
then again, isn't it the shell who locates the interpreter and passes on the script? then the whole shebang thing is shell syntax and it is the shell's responsibility (and solely the shell's responsibility) to parse the whole thing and pass the correct argument to whatever interpreter. the interpreter has no business having to parse this argumen
Is there reflection for private methods (Score:2)
One of the problems that I ran into when trying to learn nodejs is that there are no unit test frameworks that support whitebox testing _and_ encapsulation. With Java, the PowerMock library is a powerful friend that allows one to write test cases that change the behavior of private methods which are invoked from the method under test (or even deeper in the call stack). One can do this in Javascript with some test libraries if one does not use classes and private methods (with the '#' syntax). When you use p
Re: Is there reflection for private methods (Score:2)
Private methods haven't really been in JS until very recently and most people still don't use them. There are other strategies for accomplishing something similar - like non-enumerable properties - and you absolutely can get access to those.
JS doesn't support classes though. It supports prototypes, which are a different approach to OOP. If you are having issues, it's most likely because you aren't really engaging with the type system in the way it's designed to work.
(yes, there is a "class" keyword; it came
Re: (Score:1)
Please add optional-named-parameters! (Score:2)
I'm still waiting for JS to add optional named parameters, like what C#/VB has. Love ONPs!; you can add features and feature switches without overhauling bunches of existing callers. There are ways to half-emulate them in JS, such as object literals, but they are messy and verbose in comparison.
JS keeps adding relatively obscure features for power dev's, but this is a bread-and-butter need.