- From: <bugzilla@jessica.w3.org>
- Date: Mon, 20 Feb 2012 02:40:05 +0000
- To: public-script-coord@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15986 --- Comment #14 from Allen Wirfs-Brock <allen@wirfs-brock.com> 2012-02-20 02:40:05 UTC --- (In reply to comment #13) > (In reply to comment #12) > > I would personally be fine with that. Can we survey existing usage of > > overloads in specs? > > All the existing uses of overloads that I could find are below. Many of them > can be be replaced with uses of optional and union types. The ones that cannot > be rewritten to use only overloading with different argument list lengths > (where shorter ones are all prefixes of the longer ones) are > BlobBuilder.append, CanvasRenderingContext2D.createImageData and > DataTransferItemList.add. > I would think that if there are only these three API that require overloads then it would be much more economical to treat them as special cases then it would be to provide the full complexity of the overload mechanism. If necessary, those three could be describe as (any ... args) with a prose description of the legal argument combinations. However, some of them could be more specific, for example the arguments for DataTransferItenList.add might be expressed as: ((DOMString or File) data, optional DOMString type) with the prose specification saying that the second argument is only legal when the first argument is a DOMString. Implementations for languages with overloads could always manually map these few prose descriptions back into actual language specific overloads. Using this technique and eliminating overloading would probably also discourage the creation of future APIs that are difficult to -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Monday, 20 February 2012 02:40:07 UTC