Well, you can redefine it by editing its source code file on disk. (Unless the file is read-only.) But it's a lot faster to be able to redefine it interactively inside the DevTools console and I wish there was a "dev" setting that allowed this. Also, you said "you declared it" but usually it wasn't me who declared it constant. Rather, some other programmer thought `width=800` or `numColumns=80` should be declared constant. "Variables aren't; constants won't be." No coder is an island: one programmer's bad `const` can't make life harder for other coders. Related: One reason I use Chromium browsers instead of Firefox is because in Firefox DevTools console once you declare `class A {}` you can't interactively change it to, say, add a constructor like `class A { constructor (foo) { this.foo = foo } }` During learning and experimentation this is lousy; you can't interactively iterate at the console prompt like a proper dynamic language. You must instead put your code in an external file and set up a "save file and re-run everything" system just like static languages like C++ require.
If you are the one writing entirely new code then you can choose to do that. But if you must build upon the work of a different programmer who is not you and that programmer chose `class Foo{}` instead of `Foo=class{}` then the codebase is now rigid and inflexible for purposes of prototyping and experimentation. You are going to have to save the JavaScript to a disk file and edit it there to get rid of the non-redefinable `class Foo{}` or `const numColumns=80`.
class A defines a let variable. It's how the standard define it.
You can replace A with:
A = class {...}
This works with any browser.
BTW. In Firefox there is a multi line editor. With code completion. I actually find more convenient to test large code fragments in fox because of that.
Good tip, thanks, but it means that code written like
class A {}
has a huge difference from code written like
A = class {}
In classical JavaScript consider how small the difference is between
function foo () {}
and
foo = function () {}
Function hoisting only works for the "function foo(){}" form so there's a difference but they intuitively work essentially the same and either form works well when experimenting in the console. If enough rules like "class A {} is very different from A = class {}" are piled onto JavaScript it's going to become like C++, a language so complex that people would rather learn a simpler language so they can focus on the complexities of their actual problem space rather than the complexities of their language. A new language called Zig is now trending upward because a growing number of programmers would rather have a language they can 100% understand after a reasonable time investment rather than a language like C++ where even after a 20 year career with it and implementing portions of a compiler for it you still get painfully surprised by some obscure rule interaction you never dreamed to imagine possible.
Well, you can redefine it by editing its source code file on disk. (Unless the file is read-only.) But it's a lot faster to be able to redefine it interactively inside the DevTools console and I wish there was a "dev" setting that allowed this. Also, you said "you declared it" but usually it wasn't me who declared it constant. Rather, some other programmer thought `width=800` or `numColumns=80` should be declared constant. "Variables aren't; constants won't be." No coder is an island: one programmer's bad `const` can't make life harder for other coders. Related: One reason I use Chromium browsers instead of Firefox is because in Firefox DevTools console once you declare `class A {}` you can't interactively change it to, say, add a constructor like `class A { constructor (foo) { this.foo = foo } }` During learning and experimentation this is lousy; you can't interactively iterate at the console prompt like a proper dynamic language. You must instead put your code in an external file and set up a "save file and re-run everything" system just like static languages like C++ require.