Still trying to sell Javascript? I guess it's getting harder to find cheap engineers willing to put up with it.
A Strong Mode for JavaScript
11–20 of 45 posts
Re: A Strong Mode for JavaScript
#12I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
Being able to do foo = bar.x || 3; rather than foo = bar.hasOwnProperty('x') ? bar.x : 3; is nice.
Agreed. And unless I'm reading the document wrong, this would also be prohibited in strong mode:
let x = {
keyA: "valueA"
};
x.keyB = "valueB";Re: A Strong Mode for JavaScript
#13Earlier quoted context omitted.
Being able to do foo = bar.x || 3; rather than foo = bar.hasOwnProperty('x') ? bar.x : 3; is nice.
Agreed. And unless I'm reading the document wrong, this would also be prohibited in strong mode: let x = { keyA: "valueA" }; x.keyB = "valueB";
I think they're trying to push onto [Maps].
[Maps]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Re: A Strong Mode for JavaScript
#14Earlier quoted context omitted.
use `let ` or `const `. there's no need to use `var` in ES6+, ever.
But we're going to keep it around, aren't we? Because we can always add features but we can't really remove them. It feels like JS is getting cruftier. Would it be better if var already worked like let? Sure. Will JS be better with two slightly different ways of scoping a variable, one of which you really shouldn't use? Doesn't seem like it. One more thing to explain to newcomers.
So, you're right that nothing can be removed. But you can add new things, and via mode switches (e.g. "use strict", which enables strict mode currently, or "use strong", which is planned to enable strong mode) essentially remove old ones by disallowing them in the latest "mode." Old code will continue to run, but as long as you opt-in to the new way of doing things for your new code you can enforce not using the legacy constructs in the new code.
It's important to note that the modes are on a per-function basis, so opting into the new mode doesn't break existing libraries, etc even if you call those libraries from a newer mode.
It's also worth mentioning that strong mode doesn't introduce anything new. All that strong mode does is remove features. `let` and `var` both already exist; in strong mode, only `let` does.
Re: A Strong Mode for JavaScript
#15I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
I agree and I come from a strongly typed background (.Net). It is extremely liberating and useful to just add properties to an object at any time, even ones I didn't create. Kind of like slapping a sticker on something for later reference, whereas a strong types object just explodes when apply you the sticker.
I understand that there are performances issues to doing things this way, but it seems like you could have the strong typed base while still allowing expando properties that may be slower? In .Net the added Dynamic but I find it of limited use because it must be explicitly used rather than just Object allowing it which is what you are going to get from most libraries.
Re: A Strong Mode for JavaScript
#16I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
I'm torn here. I agree that this is one of the Nice Things about javascript - I can do stuff like
let foo = opts.foo || 'default'
My worry is that Strong Mode becomes the defacto standard, and we end up losing the flexibility and expressiveness of well-written JS, and end up with static typing all over. If your JS is compact and otherwise well-formed, you can probably afford the compiler hit sometimes, knowing that code is a lot easier to write.
Re: A Strong Mode for JavaScript
#17Earlier quoted context omitted.
Agreed. And unless I'm reading the document wrong, this would also be prohibited in strong mode: let x = { keyA: "valueA" }; x.keyB = "valueB";
I think they're trying to push onto [Maps]. [Maps]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Yep, they're explicitly trying to do that.
For what it's worth, you can still use "options hashes" in your argument APIs in strong mode using objects; you just write a library function something like:
function options(options, defaults) {
// the final args start off as a clone of the default args
let args = Object.clone(defaults);
// we then loop through the keys and copy in any overrides
for(let key of Object.keys(args)) {
// ignore inherited properties and skip missing ones
if(args.hasOwnProperty(key) && options.hasOwnProperty(key)) {
args[key] = options[key];
}
}
// args now has all of the overrides from options
return args;
}
function bakeBread(ingredientOverrides) {
let ingredients = options(ingredientOverrides, {
flourType: 'whole wheat',
sugarAmount: '3 tbsp',
waterAmount: '1 cup',
milkAmount: '0.3 cups',
flourAmount: '4 cups'
});
let batter = mix(ingredients);
return bake(batter);
}
The neat thing about using named arguments with objects is that in typed variants of JS — for example, TypeScript, or perhaps someday SoundScript — you can actually typecheck them! Maps can't do that in any language I know of: by design they can contain anything.
Re: A Strong Mode for JavaScript
#18I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
It does break fundamental uses of the language. Throwing on missing properties is a near-hostile change for most current JS developers.
The given justifications for doing this, though, seem to be all about performance rather than an attempt to evolve the language.
If that's true, I think it's possible the proposal has a naming problem.
Calling it "use strong" implies that this is about evolving the JS language so that devs are spending time writing more strongly-typed code.
Calling "use optimize" would make it a lot clearer that this is not an attempt to Java-ify JS, and this is more something you'd primarily invoke for performance-critical code paths.
Re: A Strong Mode for JavaScript
#19I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
That's funny; I think that's the only part of what the document proposes I like. -- Well, okay, that's not really true; there are a lot of bits that just make sense, either because they hurt performance for little benefit (holes in arrays) or they're just dumb (arguments.caller). But I don't like gratuitously locking things down in a way that makes highly dynamically-typed code harder to write, where it doesn't seem to solve a real unavoidable performance problem: for example, the ban on constructors leaking 'this', and the oddly specific recursion limitations. In general, the document seems to express the sentiment that only statically typed code matters, which I think is short-sighted. I also dislike, among other performance-unrelated changes, the "let's fix C" syntax bits, such as banning fallthrough, which is just likely to annoy programmers familiar with C (who are used to writing code that relies on it on occasion).
However, making nonexistent property accesses silently return undefined is just an amazing way to ensure typos in property names never get caught. I don't think `foo.bar || baz` is much to sacrifice - Python, for example, has getattr(foo, 'bar', baz), which works fine, and has the benefit of returning foo.bar if it exists at all, not just if it's a truthy value.
Re: A Strong Mode for JavaScript
#20I think I like most of what this document proposes except for the following: In strong code, accessing objects (strong or not) throws on missing properties. New object properties have to be defined explicitly and cannot be removed from strong objects. To me, this seems to break a fundamental aspect of the language. I've found it very acceptable to be able to define an object literal property "on the fly." However, wi…
That's funny; I think that's the only part of what the document proposes I like. -- Well, okay, that's not really true; there are a lot of bits that just make sense, either because they hurt performance for little benefit (holes in arrays) or they're just dumb (arguments.caller). But I don't like gratuitously locking things down in a way that makes highly dynamically-typed code harder to write, where it doesn't seem…
My experience is that the python way results in long and obfuscating chains of access checks. It's a fine idea to not make it the default behaviour, but there should be a way to do a chained check a-la coffeescript's '?.' to ease deep accesses, especially since in js objects are commonly used for data structures.