Proposal: Allow Symbols behavior to treat entire Array as 1-instance variables

# Abdul Shabazz (7 years ago)

Similar to Matlabs operations on sets

Example 1:

let a=[1,2,...]; let b="I have ${a} apples now"; // b=["I have 1 apples now ", "I have 2 apples now",...]

Example 2:

let b="(${a} + ${a}) / ${a}"; // b=["(1 + 1)/1", "(2 + 2)/2",...]

...and why this is useful, I have no idea.

# kdex (7 years ago)

"I have no idea why this is useful" is a non-starter.

# Jerry Schulteis (7 years ago)

Useful or not, it can already be done clearly and concisely:

let b = a.map(x => `I have ${x} apples now`);

// If using a lot of these, try a tagged template literal:
function shabazz(strings, a) {return a.map(x => strings.join(x))}

let c = shabazz`I have ${a} apples now`;
let d = shabazz`(${a} + ${a})/${a}`;
On Friday, May 11, 2018, 12:59:14 PM CDT, Abdul Shabazz <ahshabazz2017 at gmail.com> wrote:  

Similar to Matlabs operations on sets Example 1: let a=[1,2,...];let b="I have ${a} apples now"; // b=["I have 1 apples now ", "I have 2 apples now",...]

Example 2: let b="(${a} + ${a}) / ${a}"; // b=["(1 + 1)/1", "(2 + 2)/2",...] ...and why this is useful, I have no idea.

# Abdul Shabazz (7 years ago)

I'm familiar with Array.prototyp.map functionality and I've ran into problems with it when attempting double assignments (eg. a=a.map(...)) or when omitting the RETURN keyword (eg . a.map((x)=>{1}) !=

a.map((x)=>{return 1})

I feel it needs cleaning up a bit, which is why I made such suggestion.

# Abdul Shabazz (7 years ago)

And, as an aside, i take umbrage with contributors whom require us to explain why a suggestion or a proposal is useful: Just because something can be done one way -- does not mean its the only way it should be done, if our goal in javascript is flexibility/versatility: The english language is complex because there are so many synonyms for the same word. But this is also why our language is the most concrete expressive; whereas languages like latin spanish or italian use the same word to express many things but the listener must interpret the speaker's tone in order to derive correct meaning. English may be dying language but it is the language of the machine.

# kdex (7 years ago)

Well, if we really want to delve into linguistics, it's more the opposite of what you're describing: Tons of languages have grammatical features that make English one of the most nondescriptive and ambiguous languages out there: Grammatical cases and gender, a wider variety of tenses, moods, grammatical numbers far beyond just singular and plural…

Anyway, back to the point: ES is a language where primarily due to browsers, you are often constrained to a certain syntax. It's hence often preferable if certain features can be introduced without introducing new syntax, or else you're forcing transpilers upon developers*, or you're breaking websites whose developers didn't even realize that older browsers can't parse the syntax for feature X. It might take years before you can safely assume that the majority of browsers supports X.

Therefore, while we do appreciate all kinds of ideas, at the very least you should explain why the current way to achieve the very same thing is inferior to your proposed solution and how introducing a new syntax might be justifiable.

  • If the feature can even be transpiled. For lack of a better example: You can not really transpile ES2015's Proxy to ES5 in a reasonable way.
# Jordan Harband (7 years ago)

Proposals always have a cost. Thus, every proposal always must justify why it's useful, or else it's never going to be worth making a change to the language.

# Jerry Schulteis (7 years ago)

I don't understand; a = a.map(...) works fine--not something I would write, I tend to use single assignment style.

Perhaps I misunderstood, because both of your examples produced strings, and you used the same ${} notation as template literals. Now,I think you want is some sort of syntactic sugar that does "a.map(x => <expression>)", but eliminates the need to type "map" and the arrow function. That is:

let a = [1, 2, 3];
let b = ${a} * 2; // de-sugars to a.map(x => x * 2)
// b is now [2, 4, 6]

let objs = [{foo: "bar"}, {foo: "baz"}];let foos = ${objs}.foo; // de-sugars to objs.map(x => x.foo)
 // foos is now ["bar", "baz"]

Is that correct?

On Saturday, May 12, 2018, 12:34:00 AM CDT, Abdul Shabazz <ahshabazz2017 at gmail.com> wrote:  

I'm familiar with Array.prototyp.map functionality and I've ran into problems with it when attempting double assignments (eg. a=a.map(...)) or when omitting the RETURN keyword (eg . a.map((x)=>{1}) != a.map((x)=>{return 1})

I feel it needs cleaning up a bit, which is why I made such suggestion.

# Abdul Shabazz (7 years ago)

The committee has made it clear in their 2018 tc39 day III notes that they have enough sugar in the specification. Any further PRs are unlikely to be championed, so perhaps this is moot.