Allows handlers without arguments, and ignores void returns

[darscan]

It's nice to be able to add then handlers that don't care about the incoming value (no arguments), and/or don't affect the ongoing value (void return).

[johnyanarella]

Commented inline on your commit:

https://github.com/darscan/promise-as3/commit/3c77898c19ec45cc0343144ab4cc75d5a34048c0#src-com-codecatalyst-promise-resolver-as-P48

Thoroughly confusing that GitHub chooses to clone those into this conversation thread without context. Much easier to read through the link above.

[johnyanarella]

I'm on the fence about the issue of ignoring an undefined return. I'm concerned this might knock us out of compliance with the Promise/A+ spec. My understanding is that the return value is always a transformation. It would be perfectly legal for a Promise to explicitly resolve with undefined.

The Promises/A+ test suite may provide some guidance here.

[darscan]

Thoroughly confusing that GitHub chooses to clone those into this conversation thread without context. Much easier to read through the link above.

Yeh, but the notifications I get link me straight to the commit comments - so this list is just a consolidated view of the inline comments (which can be useful I suppose).

[darscan]

I'm on the fence about the issue of ignoring an undefined return.

I know, it's certainly dubious. However, in everyday use I have found this to be super, super nice. It is very rare to use undefined as an actual value in AS3.

I'm concerned this might knock us out of compliance with the Promise/A+ spec. My understanding is that the return value is always a transformation.

I haven't seen this explicitly stated in the spec.. But I may have missed it.

It would be perfectly legal for a Promise to explicitly resolve with undefined.

Certainly true, but I really don't think anyone will need this in reality. It is infinitely more likely that someone will want to transform the value into null, which this solution supports. I have never seen anyone explicitly set a variable to undefined.

[joeatsalot]

I'm surprised to see you guys considering the undefined return, because I too thought it wouldn't be compliant. However, I must say it'd neaten up a lot of my code, and would have helped prevent a few small bugs so far. I know it's best to follow the standard - I just want you to know that I'll be interested to see what you decide.

[johnyanarella]

While I think ignoring an undefined return value makes sense pragmatically, it directly violates the Promises/A+ specification. Consequently, I didn't integrate that particular change.

I think it would be a great idea to open a ticket on the Promises/A+ specification project about this topic. When I've observed developers who are new to Promises, they typically intuitively expect a handler that doesn't return a value to result in continued propagation of the same value. I think there's a good debate to be had about the trade-off between supporting an unlikely edge case (intentionally resolving with undefined) vs making the API more accessible to developers and eliminating a whole class of common errors. That said, I suspect this part of the specification is unlikely to change.

It's a shame it's not possible to introspect an arbitrary AS3 function to check whether it is explicitly defined with a void return type. That would leverage the stricter function parameter definitions of ActionScript (as compared to JavaScript) to disambiguate between a legitimate undefined return value and a true void return.

[darscan]

It's a shame it's not possible to introspect an arbitrary AS3 function to check whether it is explicitly defined with a void return type. That would leverage the stricter function parameter definitions of ActionScript (as compared to JavaScript) to disambiguate between a legitimate undefined return value and a true void return.

Yeh, that would be awesome.

[joeatsalot]

Awesome, I appreciate this.