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/fa6968eb/attachment-0001.html>

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 (but related) meaning when the expression on the left is omitted.

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.

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.

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.