Can we not introduce a dirty hack into the formal specification solely to work around an edge case introduced by another dirty hack that's already in the formal specification?
Will this thing really be called "thenable"? Has nobody suggested a better name?
The well known name of this behaviour is "thenable" and i think it's best to stick with well-known.
My first thought was, "What's a nable?" Then I figured it must be "then-able", but even after that I still accidentally read it as "th enable" as well. Weird, weird name.
This would also solve the case of objects that pretend to have every property as a function, e.g.: https://github.com/slmgc/Nothing
But why?
If this property would override default behavior, then it should be set to true, not false, i.e., not_thenable=true instead of thenable=false.
Not sure I buy that. Seems like avoiding the double negative is worthwhile. Not all default values need to be false, do they?
Agreed. It's a bad UX convention even; such as error alerts reading
"Are you sure you want to not save the document? [YES] [NO]"
If you consider that not setting it results in undefined which would evaluate to false then they are correct. But I don't think that needs to be the case. In reality you can default to whatever you want in which case I agree with you.