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 06:29:35 +0000
To: public-script-coord@w3.org
Message-Id: <E1RzMkh-0007j2-82@jessica.w3.org>

--- Comment #17 from Cameron McCormack <cam@mcc.id.au> 2012-02-20 06:29:32 UTC ---
(In reply to comment #16)
> > 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)
> Why is the parenthetical a requirement?  For example, for createImageData seems
> like the arg count is enough to identify the overload.  Same for
> DataTransferItemList.add.
> Even BlobBuilder.append could be rewritten as follows:
>   void append((DOMString or Blob or ArrayBuffer) data);
>   void append(DOMString text, DOMString endings);
> which would allow using the arg count to select the correct one of the two
> overloads....
> Or is the proposal to get rid of argcount-based overloading altogether (except
> for the special case optional arguments provide)?  But then you also can't
> express the case from comment 10.

I guess I was still thinking that we would want to avoid different types in the
same position in the argument list for some reason, but if we are looking at
argcount solely, then you're right it doesn't matter.  I'm happy with this.

As a reminder, if we have cases like

  ImageData createImageData(double sw, double sh);
  ImageData createImageData(ImageData imagedata);

then calling createImageData(0) will throw a TypeError (0 is not an ImageData
object) and calling createImageData(anImageData, 0) will be equivalent to
calling createImageData(NaN, 0).  That's the same as the behaviour required

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 06:29:36 UTC

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