Re: `String.prototype.trimStart`/`String.prototype.trimEnd` with a given string
`trimStart` and `trimEnd` are better-named versions of the very very
long-existing `trimLeft` and `trimRight`, which lack this ability, along
with ES5's `trim`.
It wouldn't make sense for these three to differ.
It certainly seems like a potential language proposal to add a string
argument to all three; however, at what point is that reimplementing
`string.replace(/^(foo)+/, '')`, `string.replace(/(foo)+$/, '')`, and
`string.replace(/^(foo)+|$(foo)+$/, '')`? How common is the use case to
trim matching substrings off of the ends of a string? (the use cases for
padding were quite common)
On Sun, Jun 23, 2019 at 12:14 AM Jacob Pratt wrote:
> `String.prototype.padStart` and `String.prototype.padEnd` accept the
> string to pad with as their final parameter. Is there any particular reason
> `String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
> same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
> 'bar').trimEnd('bar') === 'foo'`.
>
> References:
> - https://github.com/tc39/proposal-string-pad-start-end
> - https://github.com/tc39/proposal-string-left-right-trim
>
> Jacob Pratt
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
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 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 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 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
Re: Proposal: Selector/Select Expression
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 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 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
>> 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
Re: Re: What do you think about a C# 6 like nameof() expression for
FWIW a start to ```nameofall``` using ```RegExp```
https://gist.github.com/guest271314/daa1c6455ec8a2b6b89aff245e95c615
```const nameofall =
/((const|let)\s+)\w+(?=\s+(=|in|of))|class\s+\w+(?=\s)/gi;```
TODO: handle destructuring assignment, default values, shorthand
assignments, e.g.,
```
const [{
a = 1,
b = 2
}, cd] = [...[source]];
```
Usage: ```sourceCode.match(nameofall); // ["const x", "let z", "class G"]```
On Fri, Jun 14, 2019 at 1:05 PM Stas Berkov wrote:
> Can we revisit this issue?
>
>
> In C# there is `nameof`, in Swift you can do the same by calling
>
> ```
>
> let keyPath = \Person.mother.firstName
>
> NSPredicate(format: "%K == %@", keyPath, "Andrew")
>
> ```
>
> Let's introduce `nameof` in ES, please.
>
>
> Devs from TypeScript don't want to introduce this feature in TypeScript
> unless it is available in ES (
> https://github.com/microsoft/TypeScript/issues/1579 )
>
> This feature is eagarly being asked by TypeScript community.
>
>
> I understand there are couple issues related to `nameof` feature in ES.
> They are: minification and what to do if user already has `nameof` function.
>
>
> Minification.
>
> 1. If your code to be minimized be prepared that variable names will also
> change.
>
> 2. (just a possibility) Minimizer can have option to replace
> `nameof(someVar)` with result of `nameof` function.
>
>
>
> What if user already has `nameof` function.
>
> 1. To maintain status quo we can user `nameof` function having priority
> over newly introduced language feature.
>
> 2. OR we can use `typeof` syntax, e.g. `nameof msg.userName` (// returns
> "userName" string)
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
> 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 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 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
Re: Re: Proposal: Selector/Select Expression
I was expecting that someone brings up the brackets property accessor at some
point.
I would argue that there is a bit of syntactic inconsistency since usually when
using the bracket accessors it is not preceded by a dot.
```
const getEmail = user => user["contacts"].email; // No dot between user &
["contacts"].
const getEmail = .["contacts"].email;
```
Having said that, the currently proposed Optional Chaining operator (Stage 2)
does exactly that and more:
```
obj?.prop // optional static property access
obj?.[expr] // optional dynamic property access
func?.(...args) // optional function or method call
```
So I'd say that there is consistency with what is currently being proposed.
Regarding the Optional Chaining operator, which precedes the dot. How would
that work?
It would have to be something like this, if allowed.
```
const getEmail = user => user?.contacts.email;
const getEmail = ?.contacts.email;
```
It does look odd at first, but it’s quite simple is you think about it. We are
just omitting the initial part of the expression.
More Examples with Optional Chaining operator:
```
// With optional dynamic property access.
const getUserEmail = user => user?.["contacts"].email;
const getUserEmail = ?.["contacts"].email;
// With optional function or method call.
const getJohnsEmail = getUserContacts => getUserContacts?.("John").email;
const getJohnsEmail = ?.("john").email;
```
The beauty of what is being proposed is that there is nothing new to learn or
any new weird operator introduced.
Any weirdness one might find with the expressions above will already have been
introduced by the Optional Chaining operator.
The only thing this does is to allow you to omit the initial (redundant) part
of the expression.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
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 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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
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@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
`String.prototype.trimStart`/`String.prototype.trimEnd` with a given string
`String.prototype.padStart` and `String.prototype.padEnd` accept the string
to pad with as their final parameter. Is there any particular reason
`String.prototype.trimStart` and `String.prototype.trimEnd` don't do the
same? It would be nice to have a parallel, such that `'foo'.padEnd(10,
'bar').trimEnd('bar') === 'foo'`.
References:
- https://github.com/tc39/proposal-string-pad-start-end
- https://github.com/tc39/proposal-string-left-right-trim
Jacob Pratt
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
Let me correct one thing. This proposal has nothing to do with ```|>```. > What I meant to say is that the two proposals are not interdependent or related, but since ```.p``` is to be a function retrieving the value of property ```p```, it can be used like any other function in a pipline, and iso n fact plays quite nicely with pipelines. ``` const bedroomSize = house |> getRooms |> .bedroom // pick bedroom property from rooms object |> calcRoomSize; ``` Bob ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
I am guessing this doesn't allow any operations other than the "dot path" to a function or property... Are you comfortable with that? If so, why? I have found myself doing things like a=>a.x/2 . I couldn't do that in proposed way, could I? Have you found, in your experience, that a "dot path only" return value is common enough to save you a lot of effort, and justify not being easily extendable to accept other operations, other than having to switch to the arrow syntax again, which could be cumbersome? If you are comfortable with all these things, then I have no problem with the proposal really. I wouldn't lose anything. For me it would be like the "if" clause not requiring curly braces if there's only 1 statement - I simply always use curly braces - and might simply always use arrow functions - for the purposes of extensibility - but I'm not sure. Thoughts? Have I missed something? On Sun, 23 Jun 2019 at 07:05, Bob Myers wrote: > > In any event, re-read the proposal. Am certainly not opposed to the > JavaScript language being capable of golf by default. Is the gist of the > proposal to substitute ```|>```, and or ```.``` at ```const getEmail = > .contacts.email;``` as the first character after ```=``` for `=>`, > meaning the initial ```.``` following ```=``` is interpreted as a function > call, equivalent to ```=>```? Can you include comments next to the examples > at the OP detailing what each character is intended to mean in JavaScript, > compared to the current specification of JavaScript? > > This proposal has nothing to do with ```|>```. It is a variation of dot > notation, the classic notation ```o.p``` that has been a feature of JS > since its inception, to treat ```.p``` as a function (not a function call) > taking one argument and returning the value of the property ```p``` in that > object. To put it a different way, if the object normally preceding the dot > is omitted, the construct is treated as a property picking function. It is > not a matter of the dot necessarily having to follow an equal sign, or > having some special meaning only that context; ```.p``` not preceded by an > object is a function regardless of the context. To my knowledge, there is > no ambiguity in this notation. In other words, there is no case in which a > dot not following an expression and followed by an identifier is anything > other than a syntax error at present--please correct me if I'm wrong. > > Although not mentioned in the brief propsoal, there is no logical reason > that the analogous property access syntax ```.[prop]``` could not be > allowed. There also does not seem to any reason to prohibit the use of this > construct for arrays, so ```.[0]``` could be the "head" function people > have been talking about for years. > > Bob > ___ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Proposal: Selector/Select Expression
> In any event, re-read the proposal. Am certainly not opposed to the JavaScript language being capable of golf by default. Is the gist of the proposal to substitute ```|>```, and or ```.``` at ```const getEmail = .contacts.email;``` as the first character after ```=``` for `=>`, meaning the initial ```.``` following ```=``` is interpreted as a function call, equivalent to ```=>```? Can you include comments next to the examples at the OP detailing what each character is intended to mean in JavaScript, compared to the current specification of JavaScript? This proposal has nothing to do with ```|>```. It is a variation of dot notation, the classic notation ```o.p``` that has been a feature of JS since its inception, to treat ```.p``` as a function (not a function call) taking one argument and returning the value of the property ```p``` in that object. To put it a different way, if the object normally preceding the dot is omitted, the construct is treated as a property picking function. It is not a matter of the dot necessarily having to follow an equal sign, or having some special meaning only that context; ```.p``` not preceded by an object is a function regardless of the context. To my knowledge, there is no ambiguity in this notation. In other words, there is no case in which a dot not following an expression and followed by an identifier is anything other than a syntax error at present--please correct me if I'm wrong. Although not mentioned in the brief propsoal, there is no logical reason that the analogous property access syntax ```.[prop]``` could not be allowed. There also does not seem to any reason to prohibit the use of this construct for arrays, so ```.[0]``` could be the "head" function people have been talking about for years. Bob ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
