@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
