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;
}
And then in all your functions that take options objects:
JS is still quite dynamic, even in strong mode — you can define arbitrary objects and types at runtime, and easily inspect/reflect on them — it's just a little harder to silently corrupt data.
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.
Not what I was thinking of, but I should've been more explicit. Using generics you can type the keys and values of Maps in any language with generic support that I'm familiar with: certainly C++ and Java can. But you can't make type assertions about certain values existing under certain keys: that's what structs/classes/etc are for. But, those constructs can't easily be generated at runtime, and are typed nominally: even just as a caller you have to explicitly say they inherit (or in Java, implement) a specific type. However, with TypeScript-like structural subtyping, you can do:
interface BreadIngredientOptions {
flourType?: String; // this is the syntax for optional strings
sugarAmount?: String; // ditto: it's the ? that makes it optional
// ...
}
function bakeBread(ingredientOverrides: BreadIngredientOptions) {
// ...
}
// callers don't need to explicitly inherit or implement to be type checked
// however, since all properties are optional, this is less interesting
bakeBread({
flourType: 'white'
});
But you can do even better than that example shows. One common problem with maps-as-named-arguments is that you can't easily determine which arguments are required and which are optional. With typed optional properties and structural subtyping you can enforce that at compile time, as follows:
interface MyArgumentInterface {
requiredArg: number;
optionalArg?: number;
}
function f(args: MyArgumentInterface) {
// ...
}
// This works:
f({
requiredArg: 10,
optionalArg: 5
});
// This also works:
f({ requiredArg: 50 });
// This statically throws at compile time:
f({ optionalArg: 10 });
It's a combination of the simple object literal syntax from raw JS that makes it easy to create objects of arbitrary types, with structural subtyping. I'm not aware of any language with the same features (but would love to be corrected!).
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:
And then in all your functions that take options objects: JS is still quite dynamic, even in strong mode — you can define arbitrary objects and types at runtime, and easily inspect/reflect on them — it's just a little harder to silently corrupt data.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.