Re: Exposing constructors of readonly interfaces to web authors

On Tue, Jul 1, 2014 at 9:23 AM, Dirk Schulze <dschulze@adobe.com> wrote:

>
> On Jul 1, 2014, at 8:08 AM, Rik Cabanier <cabanier@gmail.com> wrote:
>
> >
> >
> >
> > On Tue, Jul 1, 2014 at 6:08 AM, Ian Hickson <ian@hixie.ch> wrote:
> > On Mon, 30 Jun 2014, Robert O'Callahan wrote:
> > > >
> > > > You're misunderstanding me. What I meant was, when taking as input an
> > > > object to a spec algorithm, you should not say "it must be a DOMRect"
> > > > (or ClientRect, or DOMRectReadOnly, or CommonSuperclassRect, or...).
> > > > You should say "it has x, y, width, height properties." That has
> > > > nothing to do with its class.
> > >
> > > I guess we would do that. Currently nothing takes a DOMRect(ReadOnly)
> as
> > > an input, so this hasn't come up.
> >
> > The way we normally do _input_ (passing from JS to a DOM API) in Web IDL
> > is to use a dictionary.
> >
> > We tried that in one of the earlier proposals but this didn't allow us
> to set up the inheritance scheme. We did leave DOMPointInit [1] in so you
> can pass in objects with that signature
> > I believe dictionary members are also not allowed to be readonly in
> WebIDL.
>
> Ian was talking about a dictionary as input, not as replacement for
> DOMRectReadOnly on the attribute ‘bounds’ of DOMQuad. This would mainly
> affect one of DOMQuad’s constructors: Constructor(DOMRectReadOnly rect)
> could be Constructor(DOMRectInit rect).
>
> This is independent of the issue with the 'bounds’ attribute and the
> DOMRectReadOnly interface in general.
>

Sure. The thread is getting very fractured and I'm unsure what we're
debating at this point.
I *think* we should mark the readonly classes as [NoInterfaceObject] or add
constructor to them. Maybe we also should create dictionary representations
so you can pass them to the DOM without type checking.