W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2012

[Bug 15986] Specify exactly how and when ECMAScript arguments are evaluated

From: <bugzilla@jessica.w3.org>
Date: Mon, 20 Feb 2012 02:40:05 +0000
To: public-script-coord@w3.org
Message-Id: <E1RzJAb-00038y-V0@jessica.w3.org>

--- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:05 UTC