Discuss
  • please add x .= f()

please add x .= f()

# Soni L. (9 years ago)

x .= f() should be syntax sugar for x = x.f()

x .= f().g().h() should be x = x.f().g().h()

# Bucaran (9 years ago)

-1 Please no :)

# Florent FAYOLLE (9 years ago)

Hello,

x .= f() should be syntax sugar for x = x.f()

x .= f().g().h() should be x = x.f().g().h()

+1! I've made some weeks ago a prototype of this in sweet.js: fflorent/member-access-assignment

Except that the syntax is rather =. (I have probably been influenced by the CoffeeScript's existential operator). The reverse looks fine to me too.

-1 Please no :)

Why?

Florent

# Andrea Giammarchi (9 years ago)

I want to +1 the -1, but I'll add a

Please no

instead as well.

# Brendan Eich (9 years ago)

Do not send "Please add" messages with two-line, half-baked sketches of extensions to the language. That's just injecting noise with very little signal.

The "-1" you received will be the answer if pressed from everyone on TC39, I would bet real money. Syntax is expensive, adding it for little semantic gain and some downside user-confusion risk (plus a small complexity tax hike for the language in full) is never the right answer.

That you can scratch this itch (and many others like it) via sweet.js does not argue for incorporating any such =. or .= operator into the core language. Analyze developer patterns and nearby languages for better candidate extensions that solve more serious usability or greater issues.

# myemailum14 at gmail.com (9 years ago)

Please no, while i can see how logically it's derived from a = a + 1

a = a.f()

a .= f()

seems like a bad idea

i can hardly see the dot why would i replace the object from which i'm calling the method in most cases looks inefficient

# Alexander Jones (9 years ago)

Not sure if trolling...

# Andrea Giammarchi (9 years ago)

not only it's badly readable and reminds me the PHP string concatenation, but it promotes different type assignment which is a performance, and virtually strongly typed, anti-pattern.

I think Brendan said already it all, the proposal is badly described, and it solve pretty much nothing in the real world.

Probably we can just move on and ignore the list of -1 we'll all put in? ;-)

Best

# Andrea Giammarchi (9 years ago)

had same feeling just reading the initial email ... fakedme+es@ ...

# Soni L. (9 years ago)

Welp I keep replying this wrong (how should I configure my email client?)

It /could/ in theory be used like this:

function path(s) { if (s.charAt(0) == '/') { s.=substring(1); } // your stuff here }

# Jordan Harband (9 years ago)

For that, you'd do if (s.charAt(0) === '/') { s = s.slice(1); } - which is only slightly more verbose than your example, without the burden of new syntax.

# Isiah Meadows (9 years ago)

That's not really the point.

The suggestion is this instead:

if (s[0] === '/') s = s.slice(1);
if (s[0] === '/') s .= slice(1);

This already exists in CoffeeScript and most derivatives/dialects.

s .= slice 1 if s[0] is '/'

Don't know of any other languages that have an equivalent, though.

# Iago Sousa (9 years ago)

I vote for no. There is no performance gain and I can hardly see anyone using it. Em seg, 10 de ago de 2015 às 22:18, Isiah Meadows <isiahmeadows at gmail.com>

escreveu:

# Bergi (9 years ago)

Isiah Meadows schrieb:

That's not really the point.

The suggestion is this instead:

if (s[0] === '/') s = s.slice(1);
if (s[0] === '/') s .= slice(1);

This already exists in CoffeeScript and most derivatives/dialects.

s .= slice 1 if s[0] is '/'

Don't know of any other languages that have an equivalent, though.

Really? Which version of CS, or which dialect are you using? It doesn't work for me in the online tool coffeescript.org/#try:s %3D "%2Fsomething" s .%3D slice 1 if s[0] is '%2F'.

But if you're that much inclined to save single characters, I'd recommend to use

s = s.slice(s[0] == '/');

Bergi

# Isiah Meadows (9 years ago)

Okay... Maybe not CoffeeScript (don't normally use it), but I know a few notable derivatives have that (particularly Coco and LiveScript).

As for the idea itself, still a -1 from me. Unless we add an equivalent for every binary operator, it's not much of an addition. It's just another special case, another band aid. Unless your identifier is 30+ characters, I don't see much benefit. Unlike with numeric operators or string building, this isn't nearly as common beyond that one case (string/array slicing). And for a single character identifier, you're only really saving 1 character. 2 for 2-character identifiers.

There's also no performance gain from it, just sugar. And in the LiveScript code I've seen (a language with this operator), I still rarely see it. That's with a community that enjoys experimenting with the syntax, almost gaming it at times. (Well, there was talk a few months ago about where sugar can become a problem itself, especially when there's 2-3 ways to write 7-8 basic constructs. 1)