- From: Boris Zbarsky <notifications@github.com>
- Date: Mon, 13 Feb 2017 10:00:22 -0800
- To: heycam/webidl <webidl@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <heycam/webidl/issues/307/279470737@github.com>
Anyway, to answer @domenic's original question * Examples of things that are easier to express as overloads: the fact that certain numbers of arguments are nonsensical, the fact that certain arguments are ignored or nonsensical depending on what values get passed for other arguments, return types that depend on argument types. Yes, maybe APIs should avoid some of these things. * Examples of things that are easier to express as unions or optionals: A function that takes three arguments, each of which can be `(Foo or Bar or Baz)` (esp if it's the same union for all three args) and all combinations are valid. Expressing this as overloads is... bad. Very bad. ;) * Non-obvious semantic differences: treating of trailing `undefined` arguments. Unless an overload API is writte _very_ carefully it will not do this the same way trailing optionals would have. You might want to also talk to the WebGL folks (e.g. @jdashg) about this. I know they've though some about the difference between these options in that spec, and I seem to recall that there's currently impedance mismatch at least in Gecko between what the spec IDL says and the natural way to implement the API on the C++ side, but I don't recall the details. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/heycam/webidl/issues/307#issuecomment-279470737
Received on Monday, 13 February 2017 18:01:01 UTC