There are 3 changes/additions to JavaScript which I think would make my work in JavaScript programming much more easy (and fun).
- Have a very short alias for “function”
- Avoid need for parentheses around function (or even method) calls (or even possibly definitions)
- Allow object destructuring and allow destructuring (of arrays or objects) within function definitions
Short alias for “function”
This is JavaScript. We use functions for everything: “classes”, as data, etc. Let’s please drop the need for this long name… “def” is used in Python, how about that?
No parentheses needed around function calls or even definitions
I was checking out some old Apple IIe BASIC files and was not only nostalgic, but sad that one can’t just quickly type up a program like in those days. I don’t like having to reach around something to put something redundant at the end.
How much I’d like to just do this when debugging:
alert testVar
And even this:
function myName param1, param2 {
}
Allow object destructuring and allow destructuring within function definitions
Object destructuring, where objects preserve property order (depends on predictable iteration order, genuine deletability of properties including their position, etc.)
[n, n2] = {num1: 123, num2:456};
alert n+n2; // 579
[k:v, k2:v2] = {num1:123, num2:456};
alert k2+':'+v2; // "num2:456"
Object destructuring, where objects don’t need to have properties in order
Get only the properties we need:
{prop:property} = {something: 'someValue', prop: 'val'};
alert property; // 'val'
Assuming variable can be defined with same name as property, we can use this simple form (esp. useful for functions–see next section):
{prop} = {something: 'someValue', prop: 'val'};
alert prop; // 'val'
Destructuring within function definitions
Especially in function libraries where one cannot easily change the API without pain for its consumers, it is nice for functions to accept (unordered) objects for configurability so that new configuration options do not disturb the existing API.
This also avoids the need for the user to remember the order of the function’s arguments (though they have to remember the more semantic property names), and it makes clear in the calling code (without needing to check the called function) how the called function is being used,
However, currently in JavaScript, it is a bit of a pain to write such such an API.
function listPrefs (obj) {
var newPrefName1 = obj.pref1,
newPrefName2 = obj.pref2,
newPrefName3 = obj.pref3;
alert(newPrefName1+newPrefName2+newPrefName3);
}
But in object destructuring (especially the unordered kind), we can do this,
keeping everything in the function’s parameter declaration:
function listPrefs ({pref1:newPrefName1, pref2:newPrefName2, pref3:newPrefName3}) {
alert(newPrefName1+namePrefName2+namePrefName3);
}
And even more succinctly, where we don’t need to rename the variable, to just be able to do this:
function listPrefs ({pref1, pref2, pref3}) {
alert(pref1+pref2+pref3);
}
Or yet further abbreviated, but with the same potential conflicts as the ‘with’ statement:
function listPrefs ({}) { // Empty could represent importing all properties into local scope (an empty object here otherwise would have no use)
alert(pref1+pref2+pref3);
}
Note that the preferences in these scenarios do not need need to be in that order on the object; for that, we would use an array–which has the connotation of being ordered:
function listPrefs ([key1:val1, key2:val2]) {
alert(key1+':'+val1+'\n'+key2+':'+val2);
}
If we didn’t care about a key (or on the other hand, if we didn’t care about a value), but we did care about the order, we could do:
function listPrefs ([key1:, :val2]) {
alert(key1+':'+val2);
}
Actually, for cases where we don’t care about the key, we could simply treat as an array, by dropping the initial colon:
function listPrefs ([key1:, val2]) {
alert(key1+':'+val2);
}
And of course, this ought to work for regular numeric arrays as well:
function listPrefs ([val1, val2]) {
alert(val1+':'+val2);
}
Or to bring together all of our innovations:
def listPrefs {pref1, prop2:val2} { // Reuse name of property in one case, and rename in the other
alert pref1+','+val2;
}
Looks clean and succinct, and let’s us focus on the business of programming (and our users focus on our API without requiring us to use JSDocToolkit syntax or the like, at least for the sake of knowing what property names are expected/allowed).
Besides avoiding the function body being cluttered with distracting definitions, the above has the advantage of making explicit (and easily documents) what types of properties (in a semantic sense) that the function is expecting.
This discussion states: We decided against object property shorthand in destructuring…This would be nice and concise, but possibly so terse as to be confusing. Part of the justification of destructuring is that its syntax exactly mimics that of structuring.
While I think we can all appreciate their concern, I think this is a huge loss, particularly for the sake of function definitions. If people can understand array destructuring (not to speak of iterators or generators), then they can understand object destructuring. The concepts and appearance are not that different.