I think this could be implemented with no regard to the function
implementation, which would treat functions with and without a lexical
`this` identically.
@Caitlin I have similar doubts. Also, I don't particularly like the look of
the `#` syntax. It looks too Perl-ish.
On Mon, Oct 26, 2015, 18:28 Caitlin Potter <caitpotte...@gmail.com> wrote:
> `foo()#` would best throw an early error — theres no syntactically
> apparent `this`, so cascading doesn’t add anything useful.
>
> `foo.bar.call(baz)#` would return `foo.bar`, as the method being invoked
> is `call`, and `foo.bar` is the `this` for that method.
>
> `baz.quux = foo.bind(bar); baz.quux()#` would return `baz`, yes.
>
> But, here’s the issue — it still doesn’t deal with callable objects with a
> lexical `this`, like arrow functions — and of course it
> doesn’t help much with bound functions. So, you can get misleading results
> with the cascading operator in JS, even in this
> dramatically simplified form.
>
> I don’t really expect that this proposal (with these gotchas) would be
> able to reach consensus and make it into a ratified specification.
>
>
> On Oct 26, 2015, at 6:21 PM, Edwin Reynoso <eor...@gmail.com> wrote:
>
> @Caitlin yea that's correct, but you didn't compare what I had typed out:
>
> `foo()#` returns `undefined`
>
> `foo.bar.call(baz)#` returns `foo` (correct?)
>
> `baz.quux = foo.bind(bar)` returns `baz` (correct?)
>
> @Erik
>
> but what happens when a method returns a Number
>
> `5..toString();` // works in ES5 because the first `.` is for the decimal
>
> On Mon, Oct 26, 2015 at 6:16 PM, Caitlin Potter <caitpotte...@gmail.com>
> wrote:
>
>>
>> More like
>>
>> Foo()# // SyntaxError
>> Foo.bar()# // Foo
>> Foo.bar.baz()# // Foo.bar
>>
>> The super property thing is a harder problem. They would always return
>> `this` i guess, but I'm not sure if chaining a super method should lookup a
>> method in the prototype first, or instance first
>>
>> On Oct 26, 2015, at 6:11 PM, Edwin Reynoso <eor...@gmail.com> wrote:
>>
>> @CaitIin see what your saying which would simplify things:
>>
>> `foo()#` returns `undefined`
>> `foo.bar.call(baz)#` returns `foo` (correct?)
>> `baz.quux = foo.bind(bar)` returns `baz` (correct?)
>>
>> and as for property accessors I think they should throw, it should only
>> be for function calls, because why after getting a property would you want
>> to get the object back? The only reason I can think of is that its a getter
>> and it does have a side effect (which in my opinion its just a bad idea)
>>
>> Take `[].length` why would you actually type out `.length` if you don't
>> want it, compare to a function call which it should have a side effect.
>>
>> So these should throw:
>>
>> `[].length#` // throws
>> `({ foo: 3 }).foo#` // throws
>>
>> @Adam
>>
>> I'm not sure about that, not sure if `with()` would be brought back to
>> "good use" (I kind of always liked it) but interesting thought
>>
>> BTW I don't think you need the preceding `.` in `with` statements
>>
>> @Eric
>>
>> Other languages having `#` as comments, doesn't matter
>>
>> I don't really like that syntax because this is how it would look if you
>> had it in different lines, but that's not really up to me:
>>
>> ```JS
>> obj.(
>> f1(),
>> f2()
>> );
>> ```
>>
>> Compare that to:
>>
>> ```JS
>> obj
>> .f1()
>> #f2()
>> ```
>>
>> There's extra parentheses and having a comma, also there's already a
>> comma operator, not sure if that will confuse things.
>>
>> @Erik
>>
>> That's a nice syntax I suppose
>>
>> @Bergi
>>
>> No, the method being called is actually `bar`, but using `call` calls the
>> method `bar` with a different `this` value.
>>
>> @Bob
>>
>> I see what your saying that's actually an idea I had first, just not that
>> syntax, but that's true if the APIs are ones you wrote, there are lots of
>> APIs that are out there already and may have functions that return other
>> values that you may or may not need.
>>
>> Yea you could use that chainify function easily if you were the one
>> writing the API, but like I said above, there are methods already that may
>> return something, and what they return is useful, but sometimes you may not
>> need them. They could have a parameter as to what to return but that just
>> complicates things, having a way to do this in the languages means 2 things:
>>
>> 1. No API methods have to be changed, to do accomplish this
>> 2. APIs can then return something else, and JS can always provide a way
>> to return the object back, instead of the API having to do it.
>>
>> On Mon, Oct 26, 2015 at 1:05 PM, Bob Myers <r...@gol.com> wrote:
>>
>>> I love cool syntactic innovations as much as the next guy. I'm sure
>>> there are a bunch sitting out there waiting to be discovered that will make
>>> us all sit back in awe.
>>>
>>> But it's not a particularly new insight to observe that especially if
>>> they introduce no new basic functionality and are just sugar, then such
>>> innovations have to solve a real pain point, not have simple user-side
>>> solutions, and not eat too much into the syntactic space for better future
>>> ideas.
>>>
>>> Here, I'm really having a hard time trying to figure out what's so
>>> painful about
>>>
>>> obj.foo();
>>> obj.bar();
>>>
>>> that would lead us to introduce `.{` or `..` or `#.` to solve the
>>> problem of typing `obj` twice. The resulting code (whether
>>> `obj.foo()..bar()` or `obj.{foo(); bar()}` or `obj.foo()#.bar()`) is
>>> neither more writable, nor more readable, nor more maintainable, nor more
>>> provably correct. On the contrary. All are more obtuse, obscure, and
>>> bug-prone.
>>>
>>> As a semi-ridiculous example of a seemingly useful new syntactic
>>> structure, let me introduce the `<#>` syntax. This is a mechanism for
>>> writing an expression, enclosed in `<>`, which throws away its value and
>>> instead evaluates to a value within the expression prefixed by a
>>> (tightly-bound) `#` operator. So, for instance, I can write
>>>
>>> return <foo(#5)>;
>>>
>>> In other words, call `foo(5)`, but deem the expression to evaluate to 5
>>> and return that.
>>>
>>> The proposed `obj.foo()#.bar()` could be written as
>>>
>>> <#obj.foo()>.bar();
>>>
>>> I have no trouble imagining that this syntax could result in some more
>>> compact code, but I doubt if it would be more writable or readable. It's
>>> syntactic over-think.
>>>
>>> Another criteria for accepting new syntax ideas is that they should be
>>> general and compositional. In other words, they should solve more than one
>>> problem. Solving the single problem of "take a method call on an object and
>>> fix it up so that later stuff in the expression refers to the object
>>> instead of the result of the method call" does not meet this criteria.
>>>
>>> I mean, if you want to write chainable functions, then just write them
>>> that way.
>>>
>>> If you have non-chainable functions, and you want to make them
>>> chainable/cascadable, it's not a real problem to chainify a function:
>>>
>>> function chainify(fn) {
>>> return function() {
>>> void fn.apply(this, arguments);
>>> return this;
>>> };
>>> }
>>>
>>> obj.doSomethingChained = chainify(obj.doSomething);
>>> obj.doSomethingChained().doSomething2();
>>>
>>> If you have a whole set of APIs you want to chainify, you could take a
>>> leaf from the `promisifyAll` paradigm, and do it all at once:
>>>
>>> chainifyAll(obj);
>>>
>>> which would create methods xxxChained for all methods on the object.
>>>
>>> --
>>> 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
>>
>>
>
> _______________________________________________
> 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
