This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 25050 - Should Constructors behave like operations or (attribute) setters?
Summary: Should Constructors behave like operations or (attribute) setters?
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: WebIDL (show other bugs)
Version: unspecified
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: Cameron McCormack
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2014-03-14 07:36 UTC by Nils Barth
Modified: 2019-03-01 16:19 UTC (History)
4 users (show)

See Also:


Description Nils Barth 2014-03-14 07:36:35 UTC

throw an exception

Could we clarify that this throws exceptions for invalid arguments
the same as *operations* (not *attributes*), if this is correct?

This came up in asking what happens if you pass an invalid value for enumeration argument;
a constructor is a method (on the global object), hence presumably the same
behavior as operations (methods on interface objects): throw TypeError on invalid value.

However, it's potentially ambiguous, as constructors set *attributes*,
and for attributes assigning an invalid value is *ignored*.
Comment 1 Boris Zbarsky 2014-03-14 14:15:55 UTC
> if this is correct?

It's correct.  The normative spec for what calling a constructor does is at and directly invokes "convert to an IDL value" on the arguments.  This will throw for an invalid value of an enumeration.

> and for attributes assigning an invalid value is *ignored*.

This is done explicitly in which doesn't actually invoke "convert to an IDL value" in the enumeration case.

> as constructors set *attributes*

Not as far as WebIDL is concerned.  Any attribute setting a constructor might do would happen in the "performing the actions listed in the description of constructor with values as the argument values" step (step 5 in the "The internal [[Call]] method of the interface object behaves as follows" steps, which I sadly can't link to directly), while the handling of the constructor arguments happens in step 4 of those same staps.
Comment 2 Boris Zbarsky 2014-03-14 14:18:31 UTC
Put another way, in pseudocode a WebIDL constructor looks like this:

  function myConstructor() {
    [f, args] = selectOverloadAndCoerceArgs(arguments);

where the behavior of "f" is defined by whatever specification is defining the constructor (and might set attributes on the object, or do something else; who knows) and the coercions performed to produce "args" are defined by WebIDL.  The latter are what throws when an out-of-the-set value is passed for an enumeration.
Comment 3 Nils Barth 2014-03-26 05:08:42 UTC
(In reply to Boris Zbarsky from comment #2)

Thanks for clarifying Boris!
Agreed that the spec is unambiguous, but the behavior is a bit buried.

Perhaps a note to the effect that constructors behave like operations for arguments could be added?

For example:
Constructors and operations use the same overload resolution algorithm for identification of which overloaded operation, constructor, etc. is being called, and for conversion of the ECMAScript argument values to their corresponding IDL values.

...right after:
See section below for details on how a constructor for an interface is to be implemented, and section 4.5.3 for how a constructor for a dictionary is to be implemented.
Comment 4 Ms2ger 2019-03-01 16:19:52 UTC