@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
