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.On Mon, Aug 10, 2015 at 1:57 PM, Soni L. <[email protected]> wrote: > 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 > } > > > On 10/08/15 04:50 PM, Andrea Giammarchi wrote: > > 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 Regards > > On Mon, Aug 10, 2015 at 8:46 PM, <[email protected]> wrote: > >> 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 >> >> >> On Mon, Aug 10, 2015 at 2:07 PM, Brendan Eich < <[email protected]> >> [email protected]> wrote: >> >>> 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. >>> >>> /be >>> >>> >>> Florent FAYOLLE wrote: >>> >>>> 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: >>>> https://github.com/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 >>>> _______________________________________________ >>>> es-discuss mailing list >>>> [email protected] >>>> https://mail.mozilla.org/listinfo/es-discuss >>>> >>>> _______________________________________________ >>> es-discuss mailing list >>> [email protected] >>> https://mail.mozilla.org/listinfo/es-discuss >>> >> >> >> _______________________________________________ >> es-discuss mailing list >> [email protected] >> https://mail.mozilla.org/listinfo/es-discuss >> >> > > > _______________________________________________ > es-discuss mailing > [email protected]https://mail.mozilla.org/listinfo/es-discuss > > > -- > Disclaimer: these emails are public and can be accessed from <TODO: get a > non-DHCP IP and put it here>. If you do not agree with this, DO NOT REPLY. > > > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
