Destructuring assignment of function-call results

[ELLIOTTCABLE]

{a, b} = c is excellent when @a and @b are static properties; but it'd be very useful to be able to use a similar shorthand with dynamic values implemented as functions.

Something of the form: {a(), b()} = c, expanding to a and b being set in the local scope as the result of calls to c.a() and c.b().

Just a thought. ~<3

[danschumann]

this would open up temptations like {getTimer()} = Ob

but then you have a variable named getTimer.

Is it perhaps a bad practice to have a function that returns something and they are both named the same thing?

something like this is confusing timer = ob1.timer()
is it a function? did it already run? the names should be explicit.

so the first is the output of a timer and the 2nd is a function that outputs the same named variable?

However, it could be useful in this case:

{get('timer'): timer, getProp(): prop} = Ob

great, but if i know anything about the responses to tickets here its that they don't change coffeescript for much. look into coco or some language that's willing to play fast and loose, which is probably the reason why coffeescript was originally created, but it doesn't seem to innovate much anymore, probably because so many people depend on it and they are sick of hearing flack when changes get made.

i've seen good, simple, obvious suggestions that are basically already built into the language and are more bugfixes get rejected. so when this gets rejected don't take it personally, its just a very stagnant front in changing conventions here. I'm trying to be respectful by the way, but, I'm not wrong, this has almost no chance of going into coffeescript. </reverse psychology?>

[ELLIOTTCABLE]

There's a substantial difference between a property/getter on an object, and a local variable.

In your example, it comes across as fairly obvious, to me, that timer = obj1.timer() is referring to two different things: a ‘timer generator’ as a function, namespaced to whoever created or exposed what we're storing on our ob1; and timer, our generated timer from that API. Hell, isn't that the purpose of destructuring assignment as it is? We're overloading the meaning of blah in our code, by using {blah} = obj; now we have two decoupled instances of the name blah.

However, if that's not immediately obvious to everyone else, then … that's a serious problem with my proposal, yes. /=

I guess it comes down to whether anybody else reading this finds it equally confusing? I definitely see things like foo<local> = instance.foo<API> all over my own code, and I've never considered it problematic; I swear I see it regularly elsehwere, too, although I can't call any examples to cite to mind at the moment …

[ELLIOTTCABLE]

@danschumann as for that last paragraph, I'm very aware: #3467, #3033, #3004, #1378 …

Doesn't mean I won't keep trying! Takes genitals of steel to participate in open-source projects and deal with universally either egotistical, or exhausted, maintainers. ;)

[vendethiel]

This seems to follow the decision to remove dynamic keys.
You also have the problems of keys: In from('foo', 'bar').baz; which key do you extract? And without the dot access? And in (foo; bar) ?

[ELLIOTTCABLE]

@Nami-Doc Huh? Confused, I don't think we're talking about dynamic keys? in {foo()} = bar, we're looking at a static use of the function under the name 'foo', and a static assignment to the variable named foo, correspondingly. In neither case, is the variable-name or property-name dynamic, only the value stored in the variable.

i.e. given that,

> coffee -bpe '{foo, bar} = widget'
var bar, foo;

foo = widget.foo, bar = widget.bar;

… I propose,

> coffee -bpe '{foo(x, y), bar} = widget'
var bar, foo;

foo = widget.foo(x, y), bar = widget.bar;

[jashkenas]

As your humble maintainer that got plenty of sleep last night ... aside from further drifting towards "dynamic keys", which we don't want to do, this proposal is already inconsistent with how destructuring assignment works.

The simple version you'd try to write is:

{foo: foo()} = object

But that doesn't compile, because that means, create a variable named foo() with the value of object.foo.

The reverse notation:

{foo(): foo} = object

... is obviously syntactically invalid.

The point of destructuring assignment is to allow you to have a complex JSON structure on both the left and right sides of an assignment. Not to expand the syntax beyond that. The left hand side is supposed to be valid simple CoffeeScript.

[ELLIOTTCABLE]

Ah, I never understood that the LHS of destructuring-assignment statements was intended to be JSON-ish.

I'll throw in one last hurrah, in that I really don't think adding function-call syntax to that is much more of an extensive change than allowing the omission of the ‘keys’ in the syntax ({foo, bar} = instead of {foo: foo, bar: bar} =).

That said, I understand the argument against complicating the LHS syntactically. (=

[jashkenas]

To riposte your last hurrah — the shorthand for {url: url} is not a special property of the left-hand side. It works equally well in JSON values also. That's why it's there ;)