HipChat Sensitive Data room, Friday August 17, 2018 [7:41 AM] Henrik Lindberg:
@turbodog @TonyVu There was a question in the demo about the use of an array for the arguments. This was kind of a design choice. [7:42 AM] Henrik Lindberg:
It has to do with calling "new" on a type, and creating a serializeable object. That simply maps each given value to an attribute, and arguments is an array, so it must be one in the call. [7:44 AM] Henrik Lindberg:
That can probably be changed if we so desire. What it prevents though is to give Deferred additional arguments in the future. That could for instance be a return type check, or something that prevents a Deferred from being automatically resolved (i.e. you want it to be sent all the way to a resource provider and that the provider resolves the value (i.e. makes the call). [7:46 AM] Henrik Lindberg:
For those reasons I thought we could just as well keep the arguments as an array. [7:52 AM] Lindsey Smith:
@ReidVandewiele ^^^ [8:43 AM] Reid Vandewiele:
I filed PUP-9072 with my thoughts on the UX. I understand how an explicit array is technically more powerful in that it "leaves the door open" to potential future extensions. It's not free though; requiring an Array argument costs UX consistency and simplicity. [8:43 AM] Reid Vandewiele:
Barring a known future use case we believe would be adopted >20% of the time, I would make the UX choice to close that door in favor of simplifying how the majority of our customers will write and use Deferred. [8:44 AM] Reid Vandewiele:
...Especially if we have the option of using a different signature, e.g. Deferred( Hash ), to account for yet-unknown complex use cases in the future. |
