Proposal: Selector/Select Expression

Brian Boyko brian.boyko at gmail.com
Sun Jun 23 22:10:07 UTC 2019


I suppose what I'm making is a subjective argument, because there's no way
to precisely measure "cognitive load" or "utility," just certain rules of
thumb and guidelines passed down over the generations.

I suppose what it boils down to, is that I (subjectively) think that
there's a very high price being paid for a (subjectively) low use case,
when the existing syntax can be used without many more characters typed to
solve the problem the new syntax is trying to solve.

On Sun, Jun 23, 2019 at 10:03 PM Bob Myers <rtm at gol.com> wrote:

> Minor point, but the vast majority of JS is written in corporate
> environments where code can't even be checked in unless it lints against
> the company's standard lint rules. Modern linters support an incredible
> variety of rules, including custom rulesets.
>
> I am not saying that the availability of linters (or IDEs) should drive
> language design decisions, or that we should assume linters or IDEs are
> always used or build in dependencies on them. My point is merely that they
> do previde a way for companies to "opt out" of features that they don't
> like for some reason, and thus to some extent weaken the argument that some
> new feature is undesirable because every single JS programmer in the world
> will have to learn it.
>
>
> On Sun, Jun 23, 2019 at 4:00 AM Brian Boyko <brian.boyko at gmail.com> wrote:
>
>> > Every language feature adds cognitive overhead. It is not something
>> that can or should be avoided. It should be minimized and balanced against
>> other factors.
>>
>> True, though I'd still argue that adding a new way to generate a function
>> without either instantiating a function (with "()") or calling a function
>> (with "()")
>>
>> So - I get what you're saying.
>>
>> As for how ".p" looks like a variable assignment, I mean specifically
>> that it *doesn't* look like a function assignment (which it is) and looks
>> more like a value assignment (which it isn't.) Granted, it doesn't 100%
>> look like *either*.  And yes, while companies can choose to not allow it in
>> their own style guides, making it part of the language means that a user
>> may encounter it, especially if they're trying to figure out how imported
>> code works (not to mention, not every programmer in a company follows - or
>> even reads - the styleguide.)
>>
>> If I *had* to have this functionality in the language (and by no means
>> have I ever had any problem with "const foo = x => x.prop;") it would be
>> better to define a new keyword that more explicitly explains the purpose.
>>
>> ```
>> (window || global).propDriller = function(arrayOfProperties,
>> defaultReturn) {
>>   const driller = function(parameter, arrayOfProperties, defaultReturn) {
>>     let working = parameter;
>>     if (arrayOfProperties.length === 0) {
>>       return working;
>>     }
>>     if (working === undefined || !(working instanceof Object)) {
>>       return defaultReturn;
>>     }
>>     return driller(working[arrayOfProperties[0],
>> arrayOfProperties.slice(1), defaultReturn)
>>     }
>>   }
>>   return function(parameter) {
>>     return driller(parameter, arrayOfProperties, defaultReturn)
>>   }
>> }
>>
>> const getEmail = propDriller(['user', 0, "email'], defaultReturn)
>>
>> ```
>>
>>
>> I'd have no objection to this whastsoever (and the above could be used as
>> a polyfill). But again, this is something that I think is a bit of a
>> niche use case.
>>
>> On Sun, Jun 23, 2019 at 11:01 AM Bob Myers <rtm at gol.com> wrote:
>>
>>> Every language feature adds cognitive overhead. It is not something that
>>> can or should be avoided. It should be minimized and balanced against other
>>> factors.
>>>
>>> Whether some codebase uses the new ```.prop``` syntax, or ```R.pick```
>>> (from Ramda), or ```pluck("p")```. from RxJS, or some third-party or
>>> homegrown utility, the programmer will have to learn it. For such a common
>>> use case, it's better to have one thing for everyone to learn. Even then,
>>> as with most other features, people could choose not to use it, or a
>>> company could disallow its use in their styleguide if they really felt
>>> strongly enough about it.
>>>
>>> > The problem with the proposal, as I see it, is that it creates a
>>> function that looks, at first glance, to be a variable assignment.
>>>
>>> I don't understand this objection. How does ```.p```, which is the
>>> notation we are talking about, look like a variable assignment?
>>>
>>> As mentioned earlier in the thread, if there is concern that the leading
>>> dot is easy to overlook--which I don't think is the case, and is less of a
>>> problem in any case in most editors using monospaced fonts--there are
>>> myriad alternatives, including any non-unary operator such as ```^```, some
>>> unique combination of symbols, a keyword such as `pick`, or ```?.` where
>>> the ```?``` can be read as a placeholder for an object to be passed in
>>> later. The proposal by no means rides on the specific symbol or notation
>>> chosen. The advantage of the dot is that it is the long-established
>>> notation for property access. We are merely extending that notion by
>>> assigning a different meaning when the expression on the left is omitted.
>>>
>>>
>>>
>>> On Sun, Jun 23, 2019 at 2:31 AM Brian Boyko <brian.boyko at gmail.com>
>>> wrote:
>>>
>>>> Howdy. First post to es-discuss.
>>>>
>>>> I've been thinking about the proposal.  I would recommend against it,
>>>> main reason being that it makes the language a bit harder to read and
>>>> understand at-a-glance.
>>>>
>>>> Here's why. As an example, you've listed
>>>>
>>>> ```const getEmail = .contacts.email;```
>>>>
>>>> as a possible use case. The problem with this is that what you're
>>>> essentially doing is adding a *third* way to write a function (other than
>>>> "const foo = x => x" or "function foo (x) { return x }"
>>>>
>>>> Now, I don't mind the arrow operator since it automatically binds
>>>> "this" and makes tracking the scope of "this" easier (as well as making
>>>> "this" behave more like an object-oriented programmer coming from a
>>>> primarily OOP language would expect "this" to behave). Trick is, of course
>>>> that in so doing, we've added a "special occasion" where if we *do* need
>>>> the function to have it's own "this" scope, we need to use the longer
>>>> syntax. That "=>" is shorter to type encourages it's use as the default,
>>>> and when a coder looks at someone writing out "function" it warns them that
>>>> something funky is about to happen with "this."
>>>>
>>>> The problem with the proposal, as I see it, is that it creates a
>>>> function that looks, at first glance, to be a variable assignment. Granted,
>>>> that leading "." does look different from most variable assignments, but
>>>> it's easy to overlook. Whether it's with an arrow function or the function
>>>> keyword, when a function is defined, it is always defined with "()"
>>>> somewhere in it. It is, in fact, what makes functions *look different* at a
>>>> skim-level of reading comprehension, from things like assignments and
>>>> operations.
>>>>
>>>> By adding this new way of writing functions without () in the syntax,
>>>> you increase the cognitive overhead of the programmer, which is something
>>>> we want to avoid.
>>>>
>>>> A concise programming language is not a programming language with the
>>>> fewest characters, but the programming language with the fewest characters
>>>> *necessary to make meaning clear.* I just don't think that the proposed
>>>> syntax clearly indicates what it does, and violates the principle of least
>>>> surprise.
>>>>
>>>> So - that's my two cents as a person who isn't a language *expert*
>>>> perse but does have to use ES on a daily basis.
>>>>
>>>> It's still a good problem to solve, though, as (x) => x.some.property
>>>> does come up quite often.  But perhaps this should be a proposal in a
>>>> helper library like lodash that isn't something that all javascript
>>>> programmers learning the language need to internalise. That way you could
>>>> write:
>>>>
>>>> const getEmail = _.drill("contacts.email", value_if_undefined)
>>>> or
>>>> const getEmail = _.drill(['contacts', 'email'], value_if_undefined)
>>>>
>>>> get nearly the same amount of code golf, and be able to use it when you
>>>> need it.
>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> es-discuss at mozilla.org
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20190623/1cd0bb01/attachment.html>


More information about the es-discuss mailing list